incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Schroiff, Klaus" <Kla...@fast.au.fujitsu.com>
Subject BigCouch merge - conflict management
Date Wed, 23 Apr 2014 23:40:49 GMT
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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message