From what I have seen this project uses the Dropbox Datastore API. The Dropbox Datastore API has very limited support for conflict resolution:
- DBResolutionRemote: The remote value will be chosen. This is the default behavior for all fields.
- DBResolutionLocal: The local value of the field will be chosen.
- DBResolutionMax: The greater of the two changes will be chosen.
- DBResolutionMin: The lesser of the two changes will be chosen.
- DBResolutionSum: Additions and subtractions to the value will be preserved and combined.
So with these limited conflict resolution options conflicts might occur but they can be resolved automatically. I am not saying this is good or bad but beside setting one of those resolution modes there is nothing else to do - except explaining to users what happened to their data in the case of a conflict that should have been resolved with a more sophisticated mechanism.
iCloud+Core Data on the other hand allows custom conflict resolution on the clients.
I never felt it was a good idea to integrate context/memory, persistent store and networking into a single library. I've gotten burned with that.
The whole concept of integrating business objects with some RESTful API that is supposedly going to be soooo perfect that everything just works is funny, you're always going to run into trouble and wish things were separated so it would be easier to work with the API.
Completely agree. However I'd like to hear what solutions out there you have used that do a good job of fully encapsulating each of those roles (context/memory, persistent store and networking) and work together well out of the box or with simple adapters?
7 comments
[ 3.4 ms ] story [ 24.8 ms ] threadIs this in active use in an app yet? Would you describe it as "production ready" or more "experimental" or "beta"?
Will definitely be looking at this for an upcoming project.
If this was possible, iCloud+CoreData would have worked, and Oracle/PostgreSQL/etc would be shipping transparent, ACID, horizontally scalable RDMS.
- DBResolutionRemote: The remote value will be chosen. This is the default behavior for all fields.
- DBResolutionLocal: The local value of the field will be chosen.
- DBResolutionMax: The greater of the two changes will be chosen.
- DBResolutionMin: The lesser of the two changes will be chosen.
- DBResolutionSum: Additions and subtractions to the value will be preserved and combined.
So with these limited conflict resolution options conflicts might occur but they can be resolved automatically. I am not saying this is good or bad but beside setting one of those resolution modes there is nothing else to do - except explaining to users what happened to their data in the case of a conflict that should have been resolved with a more sophisticated mechanism.
iCloud+Core Data on the other hand allows custom conflict resolution on the clients.
The new APIs in iOS 7 do, but then you lose all the value of "transparent distributed store" and it winds up being a pretty sizable hassle.
The whole concept of integrating business objects with some RESTful API that is supposedly going to be soooo perfect that everything just works is funny, you're always going to run into trouble and wish things were separated so it would be easier to work with the API.