I have one scenario where I am not really clear on how the new Replication implementation without Resolver will work.
User A makes a change to document XYZ and saves it to the local DB
The replicator of user A will replicate the document without any conflict to the server
User A goes offline
User B now comes online
The replicator syncs document XYZ to User B
User B goes offline
User A comes back online and makes a change to document xyz
The replicator syncs document XYZ to the server
User B is still offline and will also make a change to document xyz - the save operation should work since locally there is no conflict, whereas the document already changed on the server side
User B now comes back online
The document xyz of User B wants to get synced back to the server… but now there is a conflict… what will happen? In the old version the Resolver got executed, but in d023 I don’t have one…
Sorry I didn’t test this myself. Since d023 (without the encryption function) I first need to do a lot of refactoring of the code. Before I start this work it would like to now if I can still handle the above mentioned case somehow on the user side.
In step 11, the SGW will return a 409 conflict and CBL will run a default resolver during subsequent pull. You can learn more about the automatic conflict resolution process in 2.0 in this blog
The default policy is
Deletes always win.
The most recent change (highest generation ID) wins or the revision with max revID wins if the generations are the same.i.e. – the revID that sorts higher in a simple ASCII comparison
Oh no… cb023 just became a nightmare to me. The whole point for me starting to work with CB 2.0 was the new approach to handle those Server-Side conflicts on the Client side - let the user decide which version is correct. I was under the impression that this was your vision for CB 2.0 form the beginning. With the previous Beta I didn’t expect such a huge API change. Is the resolver somehow likely to come back in future releases - just like the encryption? I don’t mind paying for those features. But with the resolver and the encryption now gone I might have to rethink my whole architecture…
Yes- indeed . Appreciate your feedback. We are evaluating how to best support custom resolver post 2.0 . We want to ensure that we architect the system so it supports relevant hooks to handle the majority of merge use cases. Stay tuned. I will DM you for specifics on use cases that apply to your application.
Thanks Priya… to be honest I am still somewhat in shocked mode and I am trying to get hold of something. When you speak about relevant hooks - would it be possible for the final release to get not only the 409 code but also the user doc from step 9 which caused the error during push replication?
That way I could build a second database which holds the user conflicts on the client side and the information wouldn’t get lost.
Later when the conflict gets resolved automatically during subsequent pull replication I can set the replicator to server branch always wins, if I understand your Blog post correctly?
Well- not really. Besides, the 409 is not exposed to Couchbase Lite. It is consumed internally. If you are interested in some of the gory details of replication, here you go.
You can’t set the replicator policy . The default policy is what is discussed in the blog.
I understand what you are trying to do here - but I don’t believe there is a good workaround in 2.0
So for now , to clarify, in your example, there would be a step 12 where document XYZ is pulled from server and the resolver will auto pick between the one from server or the locally modified one depending on the criteria mentioned in the blog.
When you speak about relevant hooks - would it be possible for the final release to get not only the 409 code but also the user doc from step 9 which caused the error during push replication?