On Mon, Jan 25, 2010 at 9:38 AM, Robert Newson <[email protected]> wrote: > 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. >> >> >
As Bob and Rob point out, it may seem easy at first blush, but replication ends up getting fairly complicated. What happens when you're trying to replicate between two servers that have different sets of revisions pinned? HTH, Paul Davis
