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