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) Regards, Brian.
