couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Candler <>
Subject Re: Removing PUT 409?
Date Tue, 07 Apr 2009 13:18:28 GMT
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:

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".



[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."

View raw message