incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <>
Subject Re: revisions and CouchDB as Temporal database
Date Thu, 19 Nov 2009 06:41:48 GMT
On Thu, Nov 19, 2009 at 1:37 AM, Paul Davis <> wrote:
> On Thu, Nov 19, 2009 at 1:12 AM, sftf <> wrote:
>> Why we need to reinvent a revision mechanism at application level,
>> instead of using existing built-in one?
>> This built-in mechanism is very useful in applications that need
>> to maintain revision history of documents (aka Temporal Database).
>> But now compaction and replication treats older versions of each document as garbage,
>> but not as document's history useful at the application level.
>> So questions is:
>> It may be useful to make this revision mechanism as the temporal feature (in sense
of transaction-time)
>> of CouchDB?
>> And for this:
>> a) invent option to compact without removing old revisions from the database and
>>   option to removing revisions older than the given timestamp
>> b) invent replication option to replicate revisions too
>> c) invent optional flexible timestamping of revisions
>> Thanks.
> While CouchDB's MVCC tokens may appear to be a replacement for
> revision systems, they are fundamentally not qualified for such a
> task. They are only a specific implementation of optimistic
> concurrency and are far removed from content tracking as would be
> required.
> Attempting to attach a temporal meaning to the MVCC tokens is also a
> fairly common reaction. This is generally born out of a misconception
> of what these tokens are for. Specifically, MVCC tokens are explicitly
> opaque. Applications are not allowed to depend on their format or
> implementation defined meaning. Attempting to attach a time based
> definition to these tokens violates many assumptions as to what they
> represent.
> HTH,
> Paul Davis

I should mention, if you're interested in a system that does include
time into its revisions, you should investigate git's implementation.
Its basically a merkle tree with conventions for what to hash. While
appearing to be quite similar to our MVCC tokens at first, you have to
remember that our tokens are meant to be reconcilable when we make
identical edits on multiple nodes, where as git tries very hard to
distinguish similar edits on different nodes.

Paul Davis

View raw message