incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Merrells <j...@merrells.com>
Subject Re: purge old revisions of documents
Date Mon, 12 Apr 2010 04:58:02 GMT

On Apr 11, 2010, at 9:30 PM, Randall Leeds wrote:

> On Mon, Apr 12, 2010 at 04:43, John Merrells <john@merrells.com> 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







Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message