Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-Id: <3B257AE4-8A98-4486-BC42-BA6D9A9423BA@apache.org>
From: Damien Katz <damien@apache.org>
To: dev@couchdb.apache.org
In-Reply-To: <20090406074001.GA7236@uk.tiscali.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: Removing PUT 409?
Date: Mon, 6 Apr 2009 12:21:17 -0400
References: <20090406074001.GA7236@uk.tiscali.com>

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"