couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joan Touzet <>
Subject Re: BigCouch merge - conflict management
Date Thu, 24 Apr 2014 02:44:04 GMT
I'll also add that, after the merge, you can still run a single node with today's semantics.
If you never replicate to that node, you'll have the approach you expect, which is the same
as CouchDB 1.6.


----- Original Message -----
From: "Klaus Schroiff" <>
Sent: Wednesday, April 23, 2014 7:40:49 PM
Subject: BigCouch merge - conflict management

Hi all,

I am "just" a user so I'm not sure where to post this because the following is about the BigCouch
Anyway ... I noticed the following link on the developer ML about the conflict management
in BigCouch:

Compared to other NoSQLs, it is at least, in my opinion, a godsend value prop of (non-Big-)CouchDB
that it provides immediate feedback upon a document collision via MVCC.
You either win or lose unless you deal with replication where we have to live with more complex
conflict resolution.
With the BigCouch merge things seems to be getting more fuzzy here.  Or to phrase it differently
- BigCouch is not drop-in compatible when relying on this mechanism.

Now I understand the reasoning behind all this but is this what we really want ?

Of course, we could alter our code as mentioned in the doc above but this appears to be a
workaround rather than a solution. And it costs performance.
I feel that it would make at least sense to have a configuration parameter where BigCouch
"simply declares a winner" rather than leaving it to the (multiple) clients to clean up the
doc revisions somehow.
In my view there should be a higher strictness of the replica handling within the cluster
compared to external replication.
Just accepting the consequences by pointing to "eventually consistency" is a bit weak IMHO.
>From my viewpoint CouchDB has two key differentiators - MVCC and replication - and MVCC
is getting less powerful then.

Thoughts ?



View raw message