incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Wolff <awo...@gmail.com>
Subject Re: revisions and CouchDB as Temporal database
Date Thu, 19 Nov 2009 16:23:03 GMT
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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message