You can already get the proposed behavior by using _bulk_docs POST and
all_or_nothing:true with a single document. We can easily add a flag
to single doc PUTs too.
The interactive conflict behavior in CouchDB is useful for completely
eliminating persisted conflicts in a lot of replicated circumstances,
such as master-slave replication, or in instances where different
documents will be only edited at a single node (like documents
pertaining to different branches offices) but replicated amongst all
nodes.
-Damien
On Apr 6, 2009, at 3:40 AM, Brian Candler wrote:
The following is part thought-experiment, part serious suggestion.
I propose the following: remove all concurrency control from PUT
operations,
and hence also the 409 response. If you PUT a document where the
_rev is not
the same as a 'head' revision, then a new conflicting version is
inserted.
[1]
The reasoning is as follows:
1. Any application which relies on the 409 PUT conflict behaviour is
not going to work properly in a multi-master replication
environment.
That is: it is protected against concurrent changes on the same
node,
but not on a different node. This is arbitrary.
2. The same reasoning was used for getting rid of bulk non-conflicting
updates. Paraphrasing: "a grown-up CouchDB app which runs on a
replicated
cluster won't be able to rely on these semantics, so removing this
capability will encourage you to write your app in a more scalable
way.
You will thank us later."
3. A CouchDB app should be written so that it "treats edit conflicts
as a
common state, not an exceptional one" [2]
This change will slightly increase the number of these normal
conflicts,
whilst forcing the app writer to deal with them.
4. By increasing the number of conflicting versions, it is likely to
exercise more the underlying code and flush out bugs (for example,
more
fully testing what happens in views when multiple conflicting
versions of
a document are updated or removed)
5. It may highlight more clearly where API improvements are needed
to help
applications deal with and resolve conflicts. For example:
- making it easier for applications to be aware of the existence of
conflicts (Maybe a GET without _rev should fail if there are
multiple
conflicting revs, or return all of the versions)
- given that multiple concurrent clients will see conflicts, and may
attempt to resolve them at the same time, then it's likely that
two
clients will independently submit exactly the same document
content
after running the conflict-resolution algorithm. It could be
helpful
if these were treated as a single new rev, and not two new
conflicts.
Comments? I would be especially interested in hearing from core
developers
who didn't want bulk non-conflicting updates, but *do* want to
retain single
non-conflicting updates, as to why this is logical.
Regards,
Brian.
[1] You can get this behaviour on 0.9.0 by POSTing to _bulk_docs with
{"all_or_nothing":true}
[2] http://couchdb.apache.org/docs/overview.html under heading
"Conflicts"
