Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of paul.joseph.davis@gmail.com
 designates 209.85.210.176 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type:content-transfer-encoding;
        b=T2iAhnHrbVEqCOWcPRuOLG65kayiqlYIyO179DJXPhkl/ocOuc/DUpi5Dijdp4sYeB
         h9oeM5fP3q32e1Dn1+ckV8AEMTX37Vxpgi/UGJxiK8A7aoLytTE2qrdKkSqpZLV8C8j5
         zZsKSZ1DJoNBkArwP5bBnlJV4R+ob9IrUl0PI=
MIME-Version: 1.0
In-Reply-To: <e2111bbb0911182237y3683b9cfue413a01ea55592cb@mail.gmail.com>
References: <1696307396.20091119121228@mail.ru>
 <e2111bbb0911182237y3683b9cfue413a01ea55592cb@mail.gmail.com>
From: Paul Davis <paul.joseph.davis@gmail.com>
Date: Thu, 19 Nov 2009 01:41:48 -0500
Message-ID: <e2111bbb0911182241s781ba598xdbd98b7991d650ea@mail.gmail.com>
Subject: Re: revisions and CouchDB as Temporal database
To: user@couchdb.apache.org, sftf <sftf-misc@mail.ru>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Thu, Nov 19, 2009 at 1:37 AM, Paul Davis <paul.joseph.davis@gmail.com> w=
rote:
> On Thu, Nov 19, 2009 at 1:12 AM, sftf <sftf-misc@mail.ru> 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 documen=
t 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 data=
base and
>> =A0 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.

HTAH,
Paul Davis