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.
