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.
-Joan ----- Original Message ----- From: "Klaus Schroiff" <[email protected]> To: [email protected] 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 merge. Anyway ... I noticed the following link on the developer ML about the conflict management in BigCouch: http://atypical.net/archive/2014/04/17/understanding-race-induced-conflicts-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 ? Thanks Klaus
