couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Newson (JIRA)" <>
Subject [jira] [Commented] (COUCHDB-1948) Introduce conflicts on normal PUT/POST request
Date Tue, 03 Dec 2013 10:24:38 GMT


Robert Newson commented on COUCHDB-1948:

I don't want to extend these tickets with meta discussion, can we move this all to the dev@
mailing list? JIRA is for bug/feature tracking, not design work.

> Introduce conflicts on normal PUT/POST request
> ----------------------------------------------
>                 Key: COUCHDB-1948
>                 URL:
>             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 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

View raw message