couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Newson (Commented) (JIRA)" <>
Subject [jira] [Commented] (COUCHDB-1367) update_seq does not always reflect the seq of the latest document update
Date Fri, 30 Dec 2011 22:46:30 GMT


Robert Newson commented on COUCHDB-1367:

I still don't see why we need do anything. My early mistaken understanding of this value should
not be used as motivation here. At the time, I was not a "couchdb committer" so the earlier
implication that it escaped even my awesome knowledge is to impute omniscience where none
is warranted.

I haven't yet fixed couchdb-lucene as the update model is rather clumsy. Simply calling _changes?since=N
instead of comparing update_seq with a local value will radically simplify that piece of couchdb-lucene.
It should improve the internals of couchdb-lucene so significantly that I would rather *not*
fix update_seq to work the way I expected years ago, in case it misleads someone into making
the same mistake I made.

That said, I wouldn't veto the change, but C-L will not depend on either the current or any
future meaning of update_seq in the next release.
> update_seq does not always reflect the seq of the latest document update
> ------------------------------------------------------------------------
>                 Key: COUCHDB-1367
>                 URL:
>             Project: CouchDB
>          Issue Type: Bug
>          Components: HTTP Interface
>    Affects Versions: 1.1.1
>         Environment: Any
>            Reporter: Henrik Hofmeister
>            Priority: Minor
>              Labels: revs_limit
> Certain operations, (currently _revs_limit and _security changes) cause the database
header's update_seq to increase when the by_seq index (and therefore _changes) has not changed,
which is confusing in light of the naming consistency.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message