revisions and CouchDB as Temporal database

[sftf <sf...@mail.ru>]

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.

Re: revisions and CouchDB as Temporal database

[Adam Wolff <aw...@gmail.com>]

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 <pa...@gmail.com>wrote:

> On Thu, Nov 19, 2009 at 1:12 AM, sftf <sf...@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
>

Re: revisions and CouchDB as Temporal database

[Paul Davis <pa...@gmail.com>]

On Thu, Nov 19, 2009 at 1:37 AM, Paul Davis <pa...@gmail.com> wrote:
> On Thu, Nov 19, 2009 at 1:12 AM, sftf <sf...@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
>

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

Re: revisions and CouchDB as Temporal database

[Paul Davis <pa...@gmail.com>]

On Thu, Nov 19, 2009 at 1:12 AM, sftf <sf...@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