couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randall Leeds <>
Subject Re: [jira] [Commented] (COUCHDB-1367) When settings revs_limit on db - the db increases its update_seq counter when viewing stats - but not when getting changes
Date Tue, 27 Dec 2011 02:02:50 GMT
On Mon, Dec 26, 2011 at 08:49, Jason Smith <> wrote:
> Hi, Bob. Thanks for your feedback.
> On Mon, Dec 26, 2011 at 12:24 PM, Robert Dionne
> <> wrote:
>> Jason,
>>  After looking into this a bit I do not think it's a bug, at most poor documentation.
update_seq != last_seq
> Nobody knows what update_seq means. Even a CouchDB committer got it wrong.
> Fine. It is "poor documentation."
> Adding last_seq into db_info is not helpful because last_seq also does
> not mean what we think it means. My last email demonstrates that
> last_seq is in fact incoherent.

Awesome. I'm glad you testing descending. Sounds like "last_seq" is a
poor name, because it applies to the particular changes request.

So then we have this other thing floating around "the sequence number
of the last replicable document change".
Interestingly, updates to _local/<id> documents don't affect update_seq.

Looking into the code, I see all the places where it's bumped
artificially. It's quite obvious, actually. Search for "update_seq+1"
in couch_db_updater.erl.

1) On setting _revs_limit
2) On setting _security
3) On some call to increment it (who knows why) that has an HTTP POST
handler in couch_httpd_misc_handlers that is not exposed by

I don't see any reason why (1) and (2) need to be bumping this number.

(3) has been there for a long time but doesn't seem to be part of the
default public API.
It appears to have been introduced by Damien in May of 2008 (333d18cf)
with the commit message:

  Experimental functionality to increment database update seq, might
go away, use at own risk.

I propose we just get rid of all these and then update_seq becomes
what everyone expects it to be.


View raw message