couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <bchesn...@gmail.com>
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 04:03:15 GMT
On Tue, Dec 27, 2011 at 3:02 AM, Randall Leeds <randall.leeds@gmail.com> wrote:
> On Mon, Dec 26, 2011 at 08:49, Jason Smith <jhs@iriscouch.com> wrote:
>> Hi, Bob. Thanks for your feedback.
>>
>> On Mon, Dec 26, 2011 at 12:24 PM, Robert Dionne
>> <dionne@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

Mmm right that confusing (maybe except if you consider update_seq as a
way to know the numbers of updates in the databases but in this case
the wording is confiusing) . Imo changes seq & commited_seq should be
quites the same. At least a changes seq should only happen when there
is a doc update ie each time and only if a revision is created.  Does
that make sense?

- benoiît

Mime
View raw message