couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Randall Leeds (Commented) (JIRA)" <j...@apache.org>
Subject [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 Mon, 26 Dec 2011 05:36:30 GMT

    [ https://issues.apache.org/jira/browse/COUCHDB-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13175892#comment-13175892
] 

Randall Leeds commented on COUCHDB-1367:
----------------------------------------

> Wait a second. Robert, you are not fixing a bug in C-L, you are working around a deficiency
in CouchDB.

Can't both be true?

> The only way to know the latest sequence id is to make a complete _changes query. Next,
follow that up with a continuous feed if you want to keep the state fresh.

Nope. You can not ever know. You always know the latest sequence number at some arbitrarily
recent point in time. If the (possibly continuous) changes feed says you're at X and you haven't
heard anything more yet, then the database is at update sequence >= X. Neveretheless, I
think I follow the sentiment. If last_seq were there one could know from an info request whether
or not more changes should be available.

> What if I want to see the most recent five changes? What if there are a hundred million
documents? What if 99% of the time, update_seq equals last_seq and so developers assume it
means something it doesn't?

In order:
 * /_changes?descending=true&limit=5
 * Not sure how this is relevant
 * This does indeed seem to cause some confusion. It clearly surprised Robert and Henrik and
it's the first I've heard of this discrepancy.

I submit that this bug is closed accurately with a suggestion to move proposals to improve
the situation over to the dev list. Off the top of my head a partial list of suggestions goes
something like:
 * Add additional information to the changes feed, perhaps with a query parameter (almost
the reverse of include docs)
 * Stop incrementing the update sequence on certain kinds of non-document changes
 * Add more information to the db information response

Please take it from there and we can work through a proposal. Thanks, everyone.
                
> When settings revs_limit on db - the db increases its update_seq counter when viewing
stats - but not when getting changes
> --------------------------------------------------------------------------------------------------------------------------
>
>                 Key: COUCHDB-1367
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-1367
>             Project: CouchDB
>          Issue Type: Bug
>          Components: HTTP Interface
>    Affects Versions: 1.1.1
>         Environment: Any
>            Reporter: Henrik Hofmeister
>            Priority: Minor
>              Labels: revs_limit
>
> If you put a number to _revs_limit on a db (to update it) - the http://host/dbname/ info
document gets an increase in update_seq number - however the changes feed does not contain
this change (while its not a change). This causes the update_seq in the dbinfo doc and the
last seq in the changes feed to differ - which breaks any application depending on the update_seq
number as the expected sequence size of the db (in my case - couchdb-lucene that will only
respond to stale requests because it thinks its not up to date)
> I know this is an edge case - but still its something fairly fundamental - that clearly
is not working as intended. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message