[
https://issues.apache.org/jira/browse/COUCHDB-1948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13837093#comment-13837093
]
Dale Harvey commented on COUCHDB-1948:
--------------------------------------
Likely worth mentioning that conflicts as first class citizens (surface on
reads, always save after validation) was agreed on in Boston
https://docs.google.com/document/d/1aeNRlLNxUrT_W5BcD5ndFh1l46VH9gFyp0Id48QhHaQ/edit
Doing so in a way that deals with compatibility gracefully will be hard, but I
think it would be a large improvement
> 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)
