Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of b.candler@pobox.com designates
 207.106.133.19 as permitted sender)
Date: Tue, 7 Apr 2009 14:18:28 +0100
From: Brian Candler <B.Candler@pobox.com>
To: Scott Shumaker <sshumaker@gmail.com>
Cc: dev@couchdb.apache.org
Subject: Re: Removing PUT 409?
Message-ID: <20090407131828.GB16013@uk.tiscali.com>
References: <261cf6280904061240r7c3388d9yf1153c8dfc286bd9@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <261cf6280904061240r7c3388d9yf1153c8dfc286bd9@mail.gmail.com>
User-Agent: Mutt/1.5.17+20080114 (2008-01-14)

On Mon, Apr 06, 2009 at 12:40:33PM -0700, Scott Shumaker wrote:
> Getting rid of conflict handling greatly limits the utility of CouchDB
> for real-world applications (it will certainly force us to adopt
> another technology instead).  And worse, this is all for the goal of
> supporting multi-master replication, which really isn't a great
> technology solution anyway.  If you want durability and scalability,
> CouchDB should really adopt the much more robust multiple write nodes
> / read nodes system (with quorum and reconciliation) in Dynamo or a
> few other distributed key/value stores.

There's a Dynamo paper here:
http://s3.amazonaws.com/AllThingsDistributed/sosp/amazon-dynamo-sosp2007.pdf

The write primitive is put(key, context, object) where 'context' includes
versioning info. Does put() ever fail simply because the object context is
stale? From reading this paper I get the impression that it doesn't, but I
could be wrong. [1]

I do like the idea that when there are multiple versions, the get()
primitive returns all of them, together with a context which refers to all
the versions included. A put() in this context will then automatically mark
the conflict as resolved.

I think it would be good for CouchDB to handle GET in the same way, rather
than picking a single arbitrary version. However, CouchDB also needs to deal
with multiple versions in views too. Would it be reasonable for a view to
contain data from *all* the live versions of a document, rather than just
one? Each map row is tagged with "id" already, so it could be tagged with
"id" and "rev".

Regards,

Brian.

[1] Section 6.3 says:

"Divergent versions of a data item arise in two scenarios. ...
The second is when the system is handling a large number of concurrent
writers to a single data item and multiple nodes end up coordinating the
updates concurrently."