views:

167

answers:

1

How does CouchDB handles conflicts while doing bi-directional replication?

For example: Lets say there are two address book databases (in server A and B). There is a document for Jack which contains contact details of Jack.

  1. Server A and B are replicated and both have the same version of Jack document.
  2. In server A, Jack's mobile no is updated.
  3. In server B, Jack's address is updated.
  4. Now when we do bi-directional replication there is a conflict.

How does couchDB handles it? If we initiate replication in a Java program, is there a way to know whether there were any conflicts from the java program?

+4  A: 

The CouchDB wiki has a detailed explanantion: http://wiki.apache.org/couchdb/Replication_and_conflicts

In a nutshell: CouchDB does not try to merge the conflicting versions. Both versions get copied into both replicas. A deterministic (but from an application-standpoint probably arbitrary) algorithm chooses one of them to be the "official" version. It will choose the same version on both replicas. Only this version will be visible by default and in views. Your application can query for the other versions, and merge them according to its needs (possibly involving the user by showing all versions on screen). If your application does not look for conflicts, one of the two updates will be effectively lost.

If you are not using the replication or bulk loading API (but the per-document REST API), the conflicting update will not make it into the database, but will be rejected with a 409 error. You have to merge before trying to update again (just like in Subversion).

Thilo