Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of awolff@gmail.com designates
 209.85.216.202 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=PFpacKoCL/POzPPJDagJh2/VIDnI6r91qJdwMaTCfQJp/keGVbk6lPkwisfGA6Cp7r
         BQWrp30JB7wnEWjvqgo9Zj9VPLxZXCrE6LFWRFKbUTj/f9MOCQvk9kOBTpUK+uw6M2e/
         gx6Jh807EwOzhv9ilSoMWTCWH9cHI9hLh10eQ=
MIME-Version: 1.0
In-Reply-To: <e2111bbb0911182237y3683b9cfue413a01ea55592cb@mail.gmail.com>
References: <1696307396.20091119121228@mail.ru>
	 <e2111bbb0911182237y3683b9cfue413a01ea55592cb@mail.gmail.com>
Date: Thu, 19 Nov 2009 08:23:03 -0800
Message-ID: <e8d26ac40911190823ybf3f88fu63c7b4137089540@mail.gmail.com>
Subject: Re: revisions and CouchDB as Temporal database
From: Adam Wolff <awolff@gmail.com>
To: user@couchdb.apache.org
Content-Type: multipart/alternative; boundary=000e0cd291d4082a470478bbc644

--000e0cd291d4082a470478bbc644
Content-Type: text/plain; charset=ISO-8859-1

If the application just stored the _rev of the document upon commit in a
separate field, couldn't you rebuild the revision history in the
application? I've been asking for a feature like this too -- but I just want
the "compaction/replication preserves revs" part.

A

On Wed, Nov 18, 2009 at 10:37 PM, Paul Davis <paul.joseph.davis@gmail.com>wrote:

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

--000e0cd291d4082a470478bbc644--