On Feb 26, 2010, at 8:27 AM, Jens Alfke <[email protected]> wrote:
If an app wants to iterate over a large view, it seems better to
page the output by issuing multiple queries, using the startkey= and
limit= parameters. However, this seems to introduce race conditions
if another client is meanwhile altering the database. I might see
half of the documents before the change and half after. For example,
I might see a document show up twice with two different key values.
Is there any way to avoid this inconsistency? In a SQL database I'd
use a transaction for this, to lock out any database updates in
between my series of SELECTs. But CouchDB's architecture doesn't
support that.
It seems like what I want is to specify some kind of clock
(timestamp / revision #) in my view queries, so they all run over
the exact same view b-tree. This seems straightforward at the level
of the CouchDB file-format, since it's append-only and the previous
view b-tree still exists in the file. But is this exposed in the API
at all?
No, but it should be. I've been tijnkjng about this for a while. Main
complication is that the old seq might not be available if a view
compaction completes in between queries.
Chris
—Jens
