Conflict Resolution using Admin REST API – How to get “Common Parent” document

Mobile Sync Gateway
1

We need to resolve conflicts server-side using the Admin REST APIs. We will use “Changes” API with “_changes?active_only=true&style=all_docs&since=nnn” to find all conflicting documents (ie having multiple leaf nodes). Then use “Get Document” API with “?open_revs=all” to obtain document data for those conflicting leaf nodes.

What we are missing is how to obtain the document data for the “Common Parent” node so that we can derive what has changed in the conflicting leaf nodes by comparing them to the common parent node. This is required for n-way-merging of the conflicts due to application semantics.

Can someone please help how we can obtain the revision of the “Common Parent” and then how to retrieve the document data for that common parent node.

We are on versions: CBL 1.4.1, SGW 1.5, CB Server 5.0.1

Thank you.

2

There is no API that will return the common parent . But more importantly, there is no guarantee that the body of the “common parent” will exist. It can get compacted away by the system . You can learn more about compaction and conflict resolution in this blog

Ideally, you would want to handle the merges at the time of write.

3

Thank you. I have read your blog and understand more now.

On the related item of the config property “allow_conflicts”… I don’t see this property described in SGW 1.5. Only see it in 2.0 documentation. Is this property applicable to 1.5?

Thanks

4

No. It is 2.x and above.
And also starting 2.x, there is automatic conflict resolution or no-conflicts mode. You can read about it here

5

Thank you.

On another related item on server side conflict resolution, we are using the bulk_docs REST API to update the winning document with merged business data and delete losing revisions. The doco of new_edits parameter in that call states:

new_edits
<<Setting this to false indicates that the request body is an already-existing revision that should be directly inserted into the database, instead of a modification to apply to the current document. This mode is used by the Couchbase Lite replicator so it can create conflicting revisions if there is already another revision at that position in the revision tree. This option must be used in conjunction with the _revisions property in the request body.>>

It appears we have to set new_edits=true to make the updates stick to the documents. But the sentence about the ‘_revisions’ property is not very clear. Does it mean we have to have the “_revisions” property present in the request body for proper functioning of bulk_docs call?

Thank you.

6

Yes. new_edits should be true. I believe that’s the default. Setting to false will create a conflicting revision. You wouldn’t need _revisions if its true. Did you try that?

7

Thanks. As I mentioned it seemed to work when new_edits set to true (the default).

I just was not sure if we had to have the _revisions node available in the document (for example by using document api with ?open_revs=all&revs=true in the call) when we call bulk_docs api. Any insight on that?

Thanks.