I created an application which works with database. I have installed that application on my both phone. Now, while using both devices i cant manage data because if transactions that are done in one device, does not show in another device, to do that i backup database from one device and restore in another device but restoring that database will ruin the database and transactions which are already in that device.
So, the thing is, I want to sync data between two of my device such that data from each device should be in another after sync
If your problem is the conflicts, you can resolve the conflict by writing the more recent records over old records. to do this:
Define a field in your records called lastEdited. you can choose a date or timestamp base on what suit you best, Though if you don't plan on displaying this values it's better defining this field as long for easier comparison later.
Each time you edit a record update the lastEdited to the current time.
After your passed the backed-up Database, read records one by one; Insert the new one but in case of conflict resolve it by comparing the lastEdited field between two records.
Hope it helps you ^^
Cheers
Related
I'm working on a Mobile App, where the main feature has the user do a lot of CRUD (Create, Read, Update and Delete) tasks within it.
The main storage of data for the App is a local sqlite database, but the user has the option to register an account and use Cloud database to backup their data.
This App needs to be able to work both offline and online. And the user should be able to use multiple devices containing the same data.
Currently in all of my sql tables I have 3 extra columns that keep track of which entries in the database is synced: createdAt(datetime), updatedAt(datetime) and synced(boolean).
With this I am able to keep track of which entries are the most recent, and update either the local or the cloud database accordingly.
I'm using Cloud Firestore as the Cloud, and using its' Offline capabilities is not a viable option in my case.
My Question is; Which solution would be the best when keeping track of deleted entries until the App is able to sync with the cloud?
One idea for a solution for this is to have an table that contains all the ID's of deleted entries together with which table it belongs, and then when the App is able to sync; remove these entries on both the local database(on all devices) and the cloud database.
The problem I have with this solution is that, this 'deletion' table quickly will become huge, and removing entries from this table would be a problem, because of the need of all the user's devices to be up-to-date before deletion and in a scenario where the user has abandoned one of his devices, this would mean that the device would never sync, resulting in the entries not being remove from the 'deletion' table.
What would your suggestion be for a robust way of tracking deleted entries?
I don't think there's a solution that satisfies both these objectives:
Don't keep deleted items in the database forever
Make sure deletions are synchronized between all devices forever
So you will have to decide which one to give up on. Your idea satisfies 2 but not 1. A solution that would satisfy 1 but not 2 is to delete the deletion records after a period of time, maybe six months. A variation on that would be when a record is deleted, rather than actually deleting it just mark it as deleted (as well as the date when it was deleted), and if applicable remove any large pieces of data from the record. After whatever grace period you decide, the record can be actually deleted. The down side is that if a mothballed device is brought back out, it could restore previously deleted records.
I have a phone application that uses a database of words and tests a user to see which words they know. I have a SQLite database with the words that I populate using a console application and this is then deployed as a resource to phones etc.
When the user runs the application then it stores pass fail data in the same database but in different tables.
When I update the application a fresh copy of the words database is installed on the phone and all the user data is lost.
How is this typically handled? Do phone applications that use SQLite have multiple databases with one being used to store user data and the other holding data which can be brought in when the application is first installed or updated?
If multiple databases are used then is it possible to create a look up from one database to the other?
Thanks in advance for any help, advice or links that point me in the right direction.
I would use a file (JSON, or plain text) to ship the words with the app. Then, when the app runs, it reads that file and adds the new words to the database. This won't affect the other tables.
Instead of having to deal with that, we hard code the values into a static method in code. Then at runtime, we see if there is any data in the table and, if not, we grab the hard coded data and do an insert.
In your case, I would also just add a version number of some kind so then, if the version was lower or the table was empty, you do a delete all and then insert your new static data.
I have a remote database that can change at any time. I need to find a way to keep my sqlite database update with all the changes in the better and optimised way possible.
I thought having a single timestamp per table and send only the updated table to the client would be one solution, or maybe having one timestamp per row and sending only the updated row to the client..
But
- how can i manage deleted items, for example?
- how can i manage the technical update on Android?
Basically, in a few words, at some point in the app, i need to download the changes with an API and update the local db.
Does anyone have some ideas?
Thanks
Since it seems this is a one-way only sync, I would:
Make each table on the server DB have a UUID column and a last
updated date/time column.
Create a REST call that will request updated data. Ideally, it would
take the time the client was updated. This date should come from the
server during the update call.
The server would scan each table searching for rows that have a date > than the date passed. Serialize the data and return it as JSON along with the server date/time for the next request.
Now tracking deletes is a bit more work. You can either:
Never delete data and only mark the rows as deleted, this is the easiest, but depending on your data may end up with lots of rows in the DB.
Delete the data and then track the deleted rows in another table. These can be deleted after some time and if/when all clients have been updated.
Have a second update call that will push down all the UUID values and time stamps for each row. The client could then figure out which rows need to be deleted.
Though it's the most complex, I'd probably opt for option 3, as I don't like old data hanging around. The direction I would go would also depend on how many clients will be syncing with the DB.
I've decided to follow another approach:
I've created an api that parse the Mysql db into an SQLITE db on the SERVER side. There is a "last_update_timestap" that will be updated every time that something will be changed.
Another api call, gives in the header an extra field containing that timestamp.
On the client side there is a Sync process that do the follow when needed:
Api call retrieving just the HEADER, getting the last update timestamp and checking if an update is needed;
If is needed download the database from the other api
Write the database into a temporary file and copy that temporary file at the position and with the same name of the real database
Use the database
Thanks everyone for the help but this turned out to be the suitable approach for my project structure.
Well, I'm building a app in both iOS and Android and both app needs to be syncronized with the cloud DB MySQL. Both the apps works offline so I need all the insert and update functionality. Delete is probably not going to be used but still I'd like to know.
Well, what I'm looking here is the solution or ideas or algo that's needs to done to achieve this.
I have kept CreatedOn and LastSync as timestamp column on each table.
Now the problem is should I always keep checking all the rows and all the columns everytime?
What I think is I should keep ModifiedOn column on all the tables and check that with LastSync for every device id. What do you guys suggest?
Maybe it's not the answer you are waiting for, but on the project I'm working on, we are using Azure Mobile Services. There is an Android and iOS SDK where they implemented synchronization between offline database and Azure (just like in Git you can call push and pull methods).
There are some limitations (TableStorage is a limited MSSQL storage), but you should check it out.
I know it's about two years overdue , but I've been doing the same thing (Android App that syncs with web api and postgresql)
What I do up to now (still researching if it's the best way, which is how I found this question) is that I keep a last_update field with a timestamp on when the data was last_updated and an altered field with a boolean on whether the data was altered (by a user action on the device)
So when I perform the sync:
I first copy the database to a backup (in case there is a problem)
I send all the rows that are marked as altered (the server handles conflicts)
then delete them
after that I find the max(last_update) value,
I subtract one minute from it
Then request all rows that have been updated after that value,(this will also also include the data I have sent because there is no way , unless there is a problem, that a row is set to altered with a last_update before the last non altered row)
It may cause some duplicate data being transfered (especially if you make A LOT of changes frequently) but in my case it's a rare phenomenon
I have an Android application which uses sqlite database to store textual data for a particular user. The data is read/written from/to the database from a service that runs periodically after every n seconds. My requirement is to clear data depending on age. Like, if the file is more than 24 hours old it should be deleted.
Checking the age of the file seems easy, just compare current time with the File creation time. The problem is:
where should I put this check and delete the file; inside application onCreate() or when the user logs in/ logs out? What would be an ideal place to trigger this logic from? Should I schedule an Alarm when the user logs in?
Should I delete the file or simply delete the rows? If I don't trigger the Cache clearance logic from login/logout, won't deleting the file cause problems, especially if the service is still trying to read and write from the database?
Please advice.
Thanks.
Well, this all depends on your logic for the application for the second part. I cant see why you would delete a database unless its just used to store temp data that does not matter. Either way the ideal place to do this check and delete is in the Data Access class thats opening the connection to the database. Below would be my logic...
Call to open DB
Check if DB file is old
If yes, delete it
Open Database (should create one if it does not exist)