You can query with stale=ok and the view won't change (as long as no other call happens without stale=ok). You'll have to call without stale=ok sometimes, though, so you'll still need to take care. Does that help?
B. On Fri, Feb 26, 2010 at 11: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? > > —Jens
