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