Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of adam.kocoloski@gmail.com
 designates 209.85.221.180 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=sender:message-id:from:to:in-reply-to:content-type
         :content-transfer-encoding:mime-version:subject:date:references
         :x-mailer;
        b=Uo3s2rbUH9Xne5Q0/+gZ60sOoIcBYWSaPkNZaWCwOIdFGvsWKc8iKjF/RayjPQU0HF
         UHtDByfdpbyk/Skacu2d3uwj6Bg1iIWPRWkQ0mF8zluXHo22hu2HA5Gj3M1QjexbZ9fk
         L5mdqi0uuffrQePpVvqvI9LbhjOcVRmTZ8bNs=
Sender: Adam Kocoloski <adam.kocoloski@gmail.com>
Message-Id: <98AECB7F-0710-4C83-BE3B-277B880C9F48@apache.org>
From: Adam Kocoloski <kocolosk@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 14:06:04 -0400
References: <20090406074001.GA7236@uk.tiscali.com>

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.

--Adam

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"