> On Sep 6, 2016, at 10:23 PM, Brendan Duddridge <[email protected]> wrote: > > I don't think so. Well at least I don't really know. It's higher level than > that. All conflict management needs to be done on the client I believe.
Looks like it does. From the docs: When you save records, the value in the savePolicy <apple-reference-documentation://hsqT9gtF9e> property determines how to proceed when conflicts are detected on the server. Because records can be modified between the time you fetch them and the time you save them, the save policy determines whether new changes overwrite existing changes. By default, the operation object reports an error if a newer version of a record is found on the server. You can change the default setting to permit your changes to overwrite the server values wholly or partially. This gives you some ability to handle conflicts, but it means that conflict resolution has to be done immediately: you can’t save data to the server until it’s resolved. This is still workable, though less flexible than Couchbase Mobile. It doesn’t interoperate well with it, though. I think you could build a sync system using CBL where the clients communicate only through CloudKit. The revision tree stuff in CBL would just be unused overhead. But you can’t combine this with CBL’s replicator — I’ve tried to figure out how to, and it just doesn’t work. If revisions can get transferred both through CloudKit [or something similar] and through the normal replicator, the versioning can get seriously confused and Bad Stuff can happen, like false conflicts and clobbered writes. —Jens -- You received this message because you are subscribed to the Google Groups "Couchbase Mobile" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/mobile-couchbase/E9E067A1-ED40-4EB2-9B18-C4FDDB7C64A9%40couchbase.com. For more options, visit https://groups.google.com/d/optout.
