Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: local policy)
From: "Schroiff, Klaus" <KlausS@fast.au.fujitsu.com>
To: "user@couchdb.apache.org" <user@couchdb.apache.org>
Subject: BigCouch merge - conflict management
Thread-Topic: BigCouch merge - conflict management
Thread-Index: Ac9fR1zNdaMuVj0KRQyDZer5ak4ovQ==
Date: Wed, 23 Apr 2014 23:40:49 +0000
Message-ID: <2945B9EFA9ECEF45930797FB76EE7A4034F2AA@SYD1214>
Accept-Language: en-AU, en-US
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_2945B9EFA9ECEF45930797FB76EE7A4034F2AASYD1214_"
MIME-Version: 1.0

--_000_2945B9EFA9ECEF45930797FB76EE7A4034F2AASYD1214_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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 confl=
ict 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 pr=
op 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 li=
ve 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 w=
ant ?

Of course, we could alter our code as mentioned in the doc above but this a=
ppears 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 (mu=
ltiple) clients to clean up the doc revisions somehow.
In my view there should be a higher strictness of the replica handling with=
in 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 replicatio=
n - and MVCC is getting less powerful then.

Thoughts ?

Thanks

Klaus

--_000_2945B9EFA9ECEF45930797FB76EE7A4034F2AASYD1214_--