incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damien Katz <>
Subject Re: Selectively keeping revisions around
Date Wed, 23 Jul 2008 17:10:09 GMT

On Jul 23, 2008, at 12:39 PM, Matthew Wilson wrote:

> On Tue 22 Jul 2008 04:50:25 PM EDT, Jan Lehnardt wrote:
>> Sorry to disappoint you.
>> Do not rely on the revisions for what you want to do.
>> Only go with the no-compaction route if you have
>> very little data.
> Hi Jan,
> I just watched the video of your talk at racklabs, and when you
> introduced the idea of revision numbers, you made a remark mentioning
> revision control.
> I'm at the very beginning of learning about couchdb.  I want to make
> sure I get this right -- are the revision numbers not meant to be used
> as a historical index going back to the beginning of time?
> Are they meant to be used as a way to handle lots of nearly parallel
> writes?

The revisions are tracked back through the beginning of time, but the  
content is not.  The availability of previous revisions is a side- 
effect of the MVCC architecture, but the revision tracking is actually  
necessary for distributed updates and replication, .

Though I'm not completely convinced this will be necessary, CouchDB  
will likely adopt a way to configure a maximum number of revisions  
tracked for a database instance, truncating revision tracking as the  
get too long.  The problem is it's possible to generate conflict  
documents if there are lots of edits between replications.  If in the  
time period between the replication of 2 nodes, a document on one node  
receives more edits than the maximum being tracked, a spurious  
conflict (old revision looks like a conflict of current revision)  
would result after replication.


View raw message