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
