[
https://issues.apache.org/jira/browse/COUCHDB-1948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13837152#comment-13837152
]
Nathan Vander Wilt commented on COUCHDB-1948:
---------------------------------------------
Is the performance impact simply reads get O(N=conflicts) more expensive on
docs? Would this be more appealing if a good solution to the general notion
expressed by [COUCHDB-1950] (ddoc conflict resolvers) were implemented as well?
Either way, the idea isn't to turn each document into a mini-database, simply
to encourage (and really, sanely enable!) a default "best practice" of
resolving conflicts *later* [after writing] instead of _before_ [the client is
even allowed to store its data].
It seems reasonable to keep the old 409 available, as it would be a potential
additional optimization for apps/architectures that want it and of course as a
migration/legacy compatibility for apps running with n=1&q=1. Main point is I'd
like to see "rejecting write conflicts" eventually become the _alternative_
(unless configured otherwise) instead of the only PUT/POST option.
> 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)
