Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Date: Tue, 3 Dec 2013 09:54:38 +0000 (UTC)
From: "Alexander Shorin (JIRA)" <jira@apache.org>
To: dev@couchdb.apache.org
Message-ID: <JIRA.12682251.1386025161941.60625.1386064478750@arcas>
In-Reply-To: <JIRA.12682251.1386025161941@arcas>
References: <JIRA.12682251.1386025161941@arcas>
Subject: [jira] [Commented] (COUCHDB-1948) Introduce conflicts on normal
 PUT/POST request
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/COUCHDB-1948?page=3Dcom.atlassi=
an.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D13=
837511#comment-13837511 ]=20

Alexander Shorin commented on COUCHDB-1948:
-------------------------------------------

Riak follows the similar approach: write first, resolve conflicts on read. =
However, this requires to have a bit different from CouchDB API and logic t=
o use. See http://docs.basho.com/riak/latest/theory/concepts/Vector-Clocks/=
 for more info.

> Introduce conflicts on normal PUT/POST request
> ----------------------------------------------
>
>                 Key: COUCHDB-1948
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-1948
>             Project: CouchDB
>          Issue Type: Improvement
>            Reporter: Nathan Vander Wilt
>
> Why does CouchDB return a 409 when a document conflicts? It should return=
 a 201 if the update didn't introduce a conflict, and maybe a 202 (or just =
a 201 with an additional "conflicted:true" response field) if the update is=
 already known to have introduced a conflict.
> AFAICT, avoiding conflicting updates at write time is useful in one and o=
nly one situation: a single-node CouchDB database (ok, for now that's still=
 all of them unless you try pretending Cloudant.com is CouchDB) that is not=
 and will never replicate in any masterless fashion. Once the BigCouch merg=
e lands this will likely become an unusual situation by default.
> "The literature" and CouchDB's current behavior encourages users and wide=
ly used CouchDB wrapper libraries to do this silly "while (409) { reattempt=
(); }" dance to avoid conflicts. But then conflicts turn up anyway when rep=
licating or (forward looking statement:) when BigCouch 202's simultaneous w=
rites. So I have to write a "reattempt until it lets me write" conflict han=
dler AND a "merge up the inevitable when noticed on read" conflict handler?
> That's lame! No wonder rumor has it that "nobody writes [actual] conflict=
 handlers".
> Since we need to allow eventual conflicts to enable eventual consistency,=
 we should remove this distracting illusion of "immediate consistency" when=
 writing. PUT/POST should simply accept the write by default, introducing a=
 conflict if necessary. We should rally around fixing conflicts eventually,=
 instead of stigmatizing them as a Client Error.
> Right now to even simulate sane behavior I have to use the confusingly na=
med for this case "all_or_nothing:true" option, or generate my own revnos [=
good luck matching the Erlang algorithm, I hear] and use "new_edits:false" =
=E2=80=94=C2=A0both only available via _bulk_docs. This has the additional =
drawback of making Couch's HTTP logs useless for debugging, as now all the =
request info and response status for every write is now hidden within the r=
epetitive drone of a single RPC-ish call.
> Just let conflicting writes introduce conflicts already!
> *breathes*
> Okay, so=E2=80=A6this is not backwards compatible. So in N.x it would nee=
d to be an opt-in parameter on PUT/POST. Then in (N+1).x probably just depr=
ecate the current behavior in the docs and raise community awareness. Then =
finally in (N+2).0 change the default behaviour of the "normal" PUT/POST ca=
lls.


--
This message was sent by Atlassian JIRA
(v6.1#6144)