On Sat, Feb 27, 2010 at 9:06 AM, Jens Alfke <[email protected]> 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
