couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <>
Subject Re: Consistent version of a view across multiple queries?
Date Sat, 27 Feb 2010 23:47:10 GMT
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.


> —Jens

Chris Anderson

View raw message