fwiw, I have the same hinky feeling about this proposal. If implemented, it would be the case that revisions are a history mechanism under user control, when couch has always, and rightly, said that it is not.
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). Purging some or all history would then be a sequence of DELETE's up to, and exclusive of, the latest version. This approach will work correctly through all compaction, replication, multi-master and offline scenarios. It's not clear if any of that belongs inside couchdb but clearly something like it would be useful to a lot of folks. Perhaps it's another tool outside of couchdb that, like couchapp, adds some finesse over a fundamental concept? B. On Mon, Jan 25, 2010 at 1:08 PM, Robert Dionne <[email protected]> wrote: > I gave this some more thought over the weekend and don't think it's a good > idea. Admittedly I'm not as deep in the code as the core devs but this > strikes me as non-trivial to get right. There has also been a lot of effort > put into telling folks to not think of _rev as a history mechanism. It seems > very doable but as you point out it needs a strategy for retention, which > would likely need to be configurable for different scenarios and there would > need to be a strategy for replication also, how much history to carry along > and so forth. > > If this is not best done by clients I think something in the server that was > entirely orthogonal, .eg. based on some changes notification and using a log > or different store, would be better. This would keep the design simpler and > enable users to leave it out if not needed. > > Just my two cents but I'd be -0 on it > > Regards, > > Bob > > > > On Jan 24, 2010, at 5:20 AM, Brian Candler wrote: > >> Have there been any more thoughts about being able to use _rev as a history >> mechanism? >> >> I think this just means that certain older _revs can survive compaction, and >> ISTM that the simplest way to achieve this would be to have a bit which >> marks a particular revision as "pinned" (cannot be discareded). This would >> be very flexible. For example, you could prune this bit so that you keep >> one revision per day for the last week, one revision per month before that, >> and so on. When making an update in a wiki, you could pin the previous >> revision only if it's more than 1 hour old, allowing multiple updates within >> this window to be coalesced. >> >> I think this would be a very convenient mechanism, and much moreso than >> building a document with all the previous versions of interest within the >> document itself, or as attachments. >> >> I've even considered introducing artificial conflicts into the database >> purely as a way to retain previous revs, but that's pretty messy. >> >> Regards, >> >> Brian. > >
