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

Jason Smith 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.

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.

That is a paper cut.

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?

Everybody wants to know the id of the latest change. Nobody wants to know the 
"update sequence," whatever that is. If CouchDB can cache last_seq in the 
header and provide it in the DB response, that would be fantastic. Kindly 
reopen this ticket, then. Thanks!
                
> 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

        

Reply via email to