[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
[ https://issues.apache.org/jira/browse/COUCHDB-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13175357#comment-13175357 ] Robert Newson commented on COUCHDB-1367: On reflection, it's couchdb-lucene's bug, not couchdb's. Let me explain. CouchDB-Lucene (to give it its grown-up name) compares the update_seq from a GET /dbname to the sequences a background process is indexing through. It then unblocks searcher threads as that process reaches or exceeds the required update_seq. This is, in fact, just silly. Instead, a search query should cause a GET /dbname/_changes?since=latest index checkpoint. It should block until it consumes the entire response, passing the updates to the indexing process. It can then return a non-stale search result. In the case that the index is fresh, the _changes response contains no rows, and serves only to confirm that the index is fresh. If, as planned, CouchDB-Lucene *also* runs a _changes?feed=continuous to keep indexes fresh in the background then indexes will simply be fresher than they would be in the CouchDB case. I repeat, CouchDB-Lucene's *mistake* is to *only* use the feed=continuous variety of the changes feed. This prevents it from knowing when its own index is fresh. I will make this change next week and I suggest that this ticket be closed with no further action taken. 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 Assignee: Bob Dionne 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
[jira] [Closed] (COUCHDB-1367) When settings revs_limit on db - the db increases its update_seq counter when viewing stats - but not when getting changes
[ https://issues.apache.org/jira/browse/COUCHDB-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Randall Leeds closed COUCHDB-1367. -- Resolution: Not A Problem Assignee: (was: Bob Dionne) Closing as Not A Problem as per Robert Newson's last comment. If this is incorrect, please re-open with a compelling argument to change this behavior. 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
[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
[ https://issues.apache.org/jira/browse/COUCHDB-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13175367#comment-13175367 ] Bob Dionne commented on COUCHDB-1367: - wonderful, I wondering about this as this is precisely how I keep up to date in my native indexer, using _changes?since and storing the last_seq in a checkpoint. 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
[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
[ https://issues.apache.org/jira/browse/COUCHDB-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13175368#comment-13175368 ] Robert Newson commented on COUCHDB-1367: The motivation for c-l's current approach is for indexes to be fresh at all times as well as updating the lucene indexes optimally (in modest sized batches). If it were purely driven by user queries, it would be variably stale, and variably well optimized, like couchdb's indexes. I wanted better for my child. 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
