On Mon, Dec 26, 2011 at 08:49, Jason Smith <j...@iriscouch.com> wrote: > Hi, Bob. Thanks for your feedback. > > On Mon, Dec 26, 2011 at 12:24 PM, Robert Dionne > <dio...@dionne-associates.com> 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 etc/couchdb/default.ini. 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. -Randall
