On Sat, Feb 27, 2010 at 9:06 AM, Jens Alfke wrote: > > 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. > We should definitely be discussing this on dev@ In a nutshell what we've discussed before is basing the view etag on the last seq-id of the database which changed anything in the index. We already track this at a view-group (design document) level but don't expose it. To do it for a single view in a group, we'd have to do some additional coding. > 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? All this sounds doable at a cost of complexity. But we are getting toward the time to think about "post-1.0" optimization etc, so it's worth researching. Chris > > —Jens -- Chris Anderson http://jchrisa.net http://couch.io