On Feb 26, 2010, at 10:56 AM, Chris Anderson wrote: > No, but it should be. I've been tijnkjng about this for a while.
Cool :) My immediate idea is to return a _rev key in a view result, like a document, whose value changes each time the view is rebuilt. In a query you could optionally add something like "&rev=" to specify which revision to use. Of course now you have to store a mapping from revision numbers to the location of the view's tree in the db file. A quick and dirty way to do this might be to optimize for only recently-obsoleted view results, and just chain the results in a linked list. So the internal data for each view b-tree would contain its _rev value, and the position in the file of the previous generation tree. [I don't know the details of the file format, though, so this might not make sense.] > Main complication is that the old seq might not be available if a view > compaction completes in between queries. Yeah, eventually you always run into that :/ Maybe compaction could optionally preserve the last couple of generations of a view? Or just specific generations that have been actively used in queries in the last N minutes? —Jens
