Mailing-List: contact couchdb-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: couchdb-user@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <ad0d04230807221424q64c4d170s15d959ea3d7212c2@mail.gmail.com>
Date: Tue, 22 Jul 2008 14:24:26 -0700
From: "Nick Gerakines" <nick@gerakines.net>
To: couchdb-user@incubator.apache.org
Subject: Re: Selectively keeping revisions around
In-Reply-To: <E5816A09-ED02-451A-AEB1-7FB6AD335A8E@apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <4E69EB4B-8914-4F9C-AD2F-D68649F91153@mubble.net>
	 <E5816A09-ED02-451A-AEB1-7FB6AD335A8E@apache.org>

The use-case that I had in mind was a wiki document. You've got a
blurb for the content and then a bunch of tuples representing
meta-data. When user A comes around and edits the wiki page the
document the new and old versions are both kept around for historical
purposes. Being able to revert a document for one reason or another is
important.

The example that I'm envisioning doesn't really use old versions for
any sort of lookups or indexing so saving them as attachments will do.

# Nick Gerakines

On Tue, Jul 22, 2008 at 1:50 PM, Jan Lehnardt <jan@apache.org> wrote:
>
> On Jul 22, 2008, at 19:22 , Kurt Mackey wrote:
>
>> I'm admittedly pretty new to CouchDB, but I'm having a tough time figuring
>> out how to use the document revisions it keeps around.  As I understand it,
>> PUTs replace what's there, leaving what's there in a deleted state until you
>> compact the database, at which point it goes away forever.
>>
>> So given that (and correct me if I got it wrong), what's the best way of
>> keeping revisions around forever?  I have a number of documents that will be
>> changed quite frequently, and I'd like to get at their history, provide
>> diffs against it, etc.  Is anyone doing this?
>
> Sorry to disappoint you.
>
> Do not rely on the revisions for what you want to do.
> Only go with the no-compaction route if you have
> very little data.
>
> To keep documents around you can do two things:
>  1) Save old revisions as attachments to the most
> recent revision.
>  2) Save old revisions as new documents.
>
> Both come with advantages and disadvantages and
> both seem clumsy in the light of possibly using the
> built in revision system. We'd like to have the revision
> system work as you want to use it, but getting it right
> with the distributed replication is kinda tricky, so we
> don't do that as of yet and you should not rely on it.
>
> 1) Advantages
> All data is available under a single doc id.
>
> 1) Disadvantages
> You need to copy around revisions manually.
> Can't use the structure of your old revisions in views.
>
> 2) Advantages
> You can use your old revisions in views.
> You can use view to collect a doc and all revisions
> (see http://www.cmlenz.net/archives/2007/10/couchdb-joins)
>
> 2) Disadvantages
> Data is spread over multiple doc ids.
>
> (There might be more, I'm kinda short on time at the moment,
> fill in the blanks please :)
>
> Cheers
> Jan
> --
>
>