Sync Function detect document conflicts


#1

In the Sync Function API documentation it says:

In the case of a document with conflicts, the current provisional winning revision is passed in oldDoc.

Is there a way to tell whether the oldDoc parameter is the previous revision or the current winning revision? If not, is there some other way to tell within the Sync Function whether the current document has conflicts?

The reason I ask is we have some cases where users should not be allowed to delete documents, but they may need to delete conflicting revisions to resolve conflicts.


#2

when you pull oldDoc and if the oldDoc has unresolved conflicts it will pick the deterministic winner by the rules below.

CouchDB guarantees that each instance that sees the same conflict comes up with the same winning and losing revisions. It does so by running a deterministic algorithm to pick the winner. The application should not rely on the details of this algorithm and must always resolve conflicts. We’ll tell you how it works anyway.

Each revision includes a list of previous revisions. The revision with the longest revision history list becomes the winning revision. If they are the same, the _rev values are compared in ASCII sort order, and the highest wins. So, in our example, 2-de0ea16f8621cbac506d23a0fbbde08a beats 2-7c971bb974251ae8541b8fe045964219.

You should have a process resolving conflicts on SG. Here is an example python script.
Just make sure it follows the same rules as CBL does on resolving conflicts.
NOTE in the up coming SG 2.x it will auto-conflict resolve , or you can use a custom one also.

One advantage of this algorithm is that CouchDB nodes do not have to talk to each other to agree on winning revisions. We already learned that the network is prone to errors and avoiding it for conflict resolution makes CouchDB very robust.
source:http://guide.couchdb.org/draft/conflicts.html

Users as in a backend Process feeding off the _changes feed?
or
User , CBL device resolving a conflict it being push back to SG?


#3

The user is on a device and resolving the conflict through CBLite.

My question isn’t really about how to resolve a conflict though. I’m wondering if there’s a way to tell within the sync function whether a document has conflicting revisions (even if the sync function can’t access those other revisions).


#4

@afeick,

function(doc,oldDoc){
.....
}

oldDoc will return the default winner when a conflict has not been resolved. It sounds like the ‘oldDoc’ has values that you are comparing ‘doc’ to that is not does not comply to your security logic and thus sync function rejects the write.

Can you still take the write but put it in channels(‘no-sync-logic-error’) and wait for your SG conflict resolution script to run.