couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kocoloski <>
Subject Re: Removing PUT 409?
Date Mon, 06 Apr 2009 18:06:04 GMT
Hi Brian, there's something about your proposal that really appeals to  
me.  I wonder if there's another variant that might be useful --  
insert a new conflicting version AND specify a 409 status code in the  
response.  The status code is a nice way to inform the client that a  
conflict occurred.


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] under heading  
> "Conflicts"

View raw message