How to ensure server version always wins during pull replication?


#1

I have a document in my local database that I want to be able to update locally but ultimately ensure that it is in sync with whatever is on the server. I.e., I want to set up a pull-only replication and ensure that the server version overrides whatever the current local version is.

My understanding that by default this won’t be the case because the revisionId on the local side will most likely be higher than the revisionId on the server side (as the local version will get updated more frequently).

I’ve read through this post a number of times (https://blog.couchbase.com/document-conflicts-couchbase-mobile/) It makes reference to a “conflict resolver” function but I can’t see any way to specify what that is using the latest version of the ObjC api.

Any advice would be appreciated.


#2

Conflict revision is now automatic, and we might bring custom conflict resolution back based on demand. The way it works now for replication is that the pull will automatically become the latest revision. Then if you try to save locally again, you can optionally specify to fail on conflict so that you won’t overwrite it automatically again (after which you could retrieve the existing revision and perform whatever logic on it).


#3

Hi Borrrden,
Thanks for your speedy reply.

Just want to clarify that I understand your reply because it seems different from what’s in the blog post I mentioned.

In the section on Pull Replication it has a scenario for “local branch is the winner”. Are you saying that this is no longer the case and that the version pulled from Sync Gateway will always win regardless of the generation-ID?

Thanks.


#4

Oops it looks like I’ve said the opposite of what happens. According to that the local revision will always be the winner in a conflict, so there might not be a way to detect what you want to do on the client side. It’s been a while since I visited this area…so I will let someone else take a stab at a solution.


#5

Ok,
Look forward to hearing back.

The process as it appears so far seems pretty useless for all practical purposes.

Consider the example where two devices go offline. If one device updates a document 6 times the other device updates it 7 times then the one that updated it 7 times automatically wins regardless on when the updates actually occurred and there’s nowhere to insert application logic to change that outcome.


#6

Based on feedback that we’ve been having on custom conflict resolution in 2.0, we have filed a GitHub ticket to track this topic in an open forum. This explains the rationale for the decision.

While we have been internally tracking the feedback that we have received from folks , we figured that it would be a good to open up the discussion to foster broader participation. Please feel free to chime in with your use case - an understanding of that would be relevant for us to determine the optimal way to architect the system . If you would rather not share your use case in an open forum, please DM with the details and we will track it internally.