How to save a copy of your TinyDB to a CloudDB
SteveJG
How to save a copy of your TinyDB to a CloudDB
Developers can 'back up' a simple TinyDB to a CloudDB. Ttransfer data using a csv file. Developers can populate an empty TinyDB from a CloudDB. The example uses the demonstration CloudDB server provided by MIT.
Here is an example showing how to backup TinyDB data from your app using the experimental CloudDB. It shows a way to handle a List of pairs List as a csv table and store the csv in the CloudDB under a single tag, then retrieve it from the CloudDB and post it to the device's TinyDB when needed. It also shows how to save a large text file (in this case the entire text of the novel Treasure Island) under a single tag in both the TinyDB and CloudDB.
The technique can also 'initialize' and fill an empty TinyDB database on a new installation of your app by downloading a file from the CloudDB to the TinyDB.
Multiple users can share the CloudDB if they all install and use the same apk on their device. If the apk is installed on several devices, all devices can modify the contents of the CloudDB because they 'share' that database. Provide code to prevent the sharing if you do not want this feature or regard the sharing as a feature amd allow users to 'share' a database with everyone. Everyone will have editing privileges.
There are downsides to 'repopulating' the TinyDB from your CloudDb. Your CloudDB should be located on your own Redis server instead of on MIT's default server if you require security. Use a log in system and enforce different unique tags for various users to prevent certain tags from being editable by all users. You get to program this nightmare yourself.
The example has minimal error control. It performs a simple comparison of the csv or text file in the TinyDB that is copied to the CloudDB as an error check. A Notifier lets you know about a successful or unsuccessful data transfer since the CloudDB control does not have an event that allows you to monitor a data transfer completion.
The csv example demonstrates working with small csv table under a single Tag. Look at the small list of pairs data stored in the Block code. A csv row can be stored equally well. You can store Lists directly rather than a csv. I did not provide the code to do that. Storing multiple tags requires a routine to loop through the tags (not provided). The app stores your TinyDB data to a database in the Cloud. Data transfer takes a few seconds to store each tag perhaps and you need to be aware how that might affect a large data transfer.
The flat text file example is 368kb. Grab the example text file stored in the Media and populate the TinyDB using the Import Test Text button. The file takes a few seconds to populate the database. The text uploads to the Cloud when you choose TinyToCloud. Uploading may take a few more seconds and you may occasionally receive error messages when you upload. This indicated the upload took too long (and the Cloud server timed out). My experience is that when you get the error message, the CloudDB at MIT/Amazon is probably busy. Try again and eventually the text will load. I have a very fast WIFI connection so I am not sure how it will perform on your system. You may have to attempt to upload several times. To confirm a valid upload if the file to the CloudDB, use the CloudToTiny button; follow instructions and after a few seconds, you should see a display of the large text file in a label. There is no tool within the CloudDB object to monitor a successful download data transfer.
Why the flat text? I wanted to get an idea of how large a file can be used without adding routines that might be necessary to slow down the saving of data and have sufficient time to ensure data transferred correctly (this is kind of like using a check sum routine). The example uses a direct 'text' comparison between the contents of the TinyDB and the CloudDB and confirm or not a valid transfer.
Is this method suitable for a large or complex database? I do not know. Test it with your data and let us know. I used only a simple data set as a proof of concept.
A similar app could be made for a FirebaseDB. It is likely MIT will be deprecating the FirebaseDB as Google changes how it can be used and modifies the requirements for developer access. The FirebaseDB controls are almost one for one duplicates of the CloudDB controls. I avoid the FirebaseDB for this reason.
Regards,
Steve