couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nathan Vander Wilt (JIRA)" <j...@apache.org>
Subject [jira] [Created] (COUCHDB-1948) Introduce conflicts on normal PUT/POST request
Date Mon, 02 Dec 2013 23:00:36 GMT
Nathan Vander Wilt created COUCHDB-1948:
-------------------------------------------

             Summary: 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 only 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 merge lands this will likely become an unusual situation by default.

"The literature" and CouchDB's current behavior encourages users and widely used CouchDB wrapper
libraries to do this silly "while (409) { reattempt(); }" dance to avoid conflicts. But then
conflicts turn up anyway when replicating or (forward looking statement:) when BigCouch 202's
simultaneous writes. So I have to write a "reattempt until it lets me write" conflict handler
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 named 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" — both 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 repetitive drone of a single RPC-ish
call.

Just let conflicting writes introduce conflicts already!

*breathes*


Okay, so…this is not backwards compatible. So in N.x it would need to be an opt-in parameter
on PUT/POST. Then in (N+1).x probably just deprecate 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 calls.



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

Mime
View raw message