On Apr 11, 2010, at 9:30 PM, Randall Leeds wrote: > On Mon, Apr 12, 2010 at 04:43, John Merrells <[email protected]> wrote: >> I now realize that the document revisions are really just a side effect >> of the implementation of the async multi master replication... as you >> need them to do the collision detection. > > Not quite. It's actually for collision detection on document updates, > or MultiVersion Concurrency Control. CouchDB exposes the revision to > the client because saving a document without specifying the latest > revision is a conflict: the client must specify the revision she > intends to update. Couch will not allow a document update if it has > changed since the client last read it.
Mmm... ok, but they're much the same thing really, as both features depend on much the same underlying state information. For LDAP, in the mult master case, we never provided the client with any consistency guarantees for the database, so an update was always against whatever state the server had at the moment the update was accepted. This worked fine for the kind of data that people were putting into LDAP directories at the time, but then, sigh, people started trying to put shopping catalog information into it, and network configuration information, etc, etc, ... what they really needed was a server with fewer information model constraints that they could store their blobs and document like things in... sounds familiar huh... Anyway, you might consider allowing the client to specify its constraint requirements, rather than just enforcing the strictest constraints upon it. Not all clients care which revision of a document their updates are applied to. I've already run into this myself this week, as multiple machines were all trying to update the same document on a single server with identical content and they got into a race... John -- John Merrells http://johnmerrells.com +1.415.244.5808
