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)
Date: Tue, 29 Apr 2014 10:55:42 -0400 (EDT)
From: Joan Touzet <joant@atypical.net>
To: user@couchdb.apache.org
Message-ID: <20808472.771.1398783341499.JavaMail.Joan@RITA>
In-Reply-To: <2945B9EFA9ECEF45930797FB76EE7A4034F80F@SYD1214>
Subject: Re: BigCouch merge - conflict management
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Yes, if you are running n=1/w=1/r=1 in BigCouch or CouchDB after the merge, you will see the same behaviour as today's CouchDB 1.x.

I will disclaim this to say that the Ektorp driver is not part of Apache CouchDB and I have no knowledge of what it does with HTTP 202 responses. Post-merge, Ektorp (and other 3rd party drivers) will need to be enhanced to understand and report 202 responses, where they arise (from n>1 scenarios).

-Joan


----- Original Message -----
From: "Klaus Schroiff" <KlausS@fast.au.fujitsu.com>
To: user@couchdb.apache.org
Sent: Tuesday, April 29, 2014 2:57:36 AM
Subject: RE: Re: BigCouch merge - conflict management

Hi Joan,

Essentially I am referring to 
https://wiki.apache.org/couchdb/HTTP_Bulk_Document_API

Section "Modify Multiple Documents With a Single Request":
"If the _rev does not match the current version of the document, then that particular document will not be saved and will be reported as a conflict, but this does not prevent other documents in the batch from being saved."

Thus is this the same behaviour in BigCouch when using [n=1] (no shard replication) ?

Thanks

Klaus

---

Thanks, Joan!

Just for the sake of clarification - ignoring implications from "external" replication:
Assuming that you configure [n=1] in BigCouch, thus no replicas of your shards - I guess that in this case, there's "a single responsible master node" since the document is hosted on exactly one server, right ?
Now in case of an update attempt using an old document revision - is the updated rejected or not ?

Maybe I am a bit confused here - the guide (http://guide.couchdb.org/draft/conflicts.html) always refers to replication in the scope of conflict management. 
I am more interested in "conventional" update conflicts during "normal" ops - no idea whether there's a difference internally. So far I assumed there is.

Please note that I am using the Ektorp Driver thus I am not all that familiar with the expected HTTP return code. All I'm seeing is a  UpdateConflictException in the case mentioned above.
I assumed that "this is it" and that I have to merge manually (perfectly fine) and that the current version won and the old version was not stored (as a loser) simply because this would be actually pretty pointless in this case.

But maybe I am assuming too much ... :-)