couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Candler <>
Subject Re: Pinning revs
Date Mon, 25 Jan 2010 21:17:42 GMT
On Mon, Jan 25, 2010 at 02:38:22PM +0000, Robert Newson wrote:
> when you PUT a new document over an existing one you are implicitly
> removing the document that was previously there. A concurrent read
> operation might see the b+tree before or after that change; either
> answer is consistent with some historical version of the database and
> no locking is required.
> If, instead, you really wanted to make a new version (from your
> applications point of view) you should insert a brand new document and
> add a view (or a naming convention) that lets you find the version
> history.
> A simple idea would be to append the version to the _id.
> (i.e, to 'update' doc1-v1, you would PUT doc1-v2).

That's what I thought of first. Given 1000 revisions of one document, stored
as 1000 separate documents, then (as you say) you can make a view to find
the most recent one.

However, you can't apply a view to a view, so it's then impossible to write
a view which makes use of only the most recent version of a document. It
becomes a bit of a mess.

So I think I need to store all the revisions within a single document.
Options might be:

1. Store all the revisions nested with the JSON document - or store the
prevision revisions as attachments.  Unfortunately, I need to version the
binary attachments too.

2. Store each attachment with a special naming convention, e.g. blob:r1,
blob:r2 etc

3. Store each rev's attachments in a single .zip file attachment.

4. Store each attachment with a name equal to its sha1, and the revisions as
nested JSON each containing an "attachments": member that points to the
sha1's.  Probably the cleanest and also saves duplicating identical content,
but still something of a PITA.

I guess that, as you say, it could be layered on-top of couchdb as some sort
of middleware, or else the client would have to take responsibility for
doing the versioning properly.

(An _update handler could update the JSON part of a multi-rev document, but
I don't think it can do clever stuff with attachments)



View raw message