|
|
|
|
|
|
by matharmin
876 days ago
|
|
|
Conceptually that's not hard, but in practice an approach like that can significantly increase the complexity of the app: 1. Do you store the tree structure for every table in your app? If you have 20 tables that could be edited offline, do you re-implement it for each table, or try to have a generic implementation?
2. Do you design all your tables around the tree structure, or do you just store it in addition to your "normal" tables?
3. Every piece of code that modifies one of these tables need to do it via the tree structure - if you update your tables directly from any place it could effectively cause conflicts.
4. Do you build separate UI to resolve conflicts for every table?
5. Do you query and cache the tree structure on the device, or does it have to be online to resolve conflicts?
6. Do you expose the tree structure via external APIs, or keep it internal? I find that "last-write-wins" is sufficient for a large percentage of cases, and much simpler to implement. Or in some cases, just doing conflict detection is sufficient (notify the user that the data has changed between loading and saving, and they need to re-apply their edits). If you do need conflict resolution on a large scale (many different tables), I'd recommend using data structures designed for that. CRDTs is one example - while it is typically used for automatic conflict resolution, it often stores enough data to allow manual resolution if desired. |
|
|
https://github.com/gerdemb/SQLiteChangesetSync
The library works at the database-level and stores databases modifications as binary change sets in a separate table that models a graph similar to a git repository. Capturing modifications is as simple as wrapping the transaction with a handler provided by the library. The graph of database modifications is stored locally on each device, but can easily by synced with an online repository.
The library detects conflicts, and provides a handler to the application for conflict resolution.