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 Re: BigCouch merge - conflict management
Date Tue, 29 Apr 2014 06:34:36 GMT
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 ... :-)


Mime
View raw message