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)
