[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=13177733#comment-13177733 ] Henrik Hofmeister commented on COUCHDB-1367: Although its hard not to agree with Robert on c-l - i still can't really see a use-case for the update_seq value - specifically why one would ever want to know that revs_limit etc. has been updated - without being able to know what has been updated. Just Something has been done - 5 times ... ? I'd say for the sake of expected output - c-l aside - this is still a bug / hidden feature - and should at the very least be documented ? 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) update_seq does not always reflect the seq of the latest document update
[ https://issues.apache.org/jira/browse/COUCHDB-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13177817#comment-13177817 ] Henrik Hofmeister commented on COUCHDB-1367: @Robert - C-L aside - its still strange that its just some 'random' number of actions taken which is not really usable to the end user. That C-L could use a different implementation is besides the point imo - Its still is usable to get the current latest update seq - for whatever reason - if even to just show a progress bar in a to-be-developed feature in some gui application or whatever. We use it internally to track progress of an aggragation application. @Randall: in terms of adding a field or whatever - my only input is - less is more - update_seq makes perfect sense naming wise, it should just be the expected value. If you'll need to track other changes than doc changes later on in terms of replication or whatever - my uneducated guess is you're gonna need to do alot more than just have a number increase in any case. But thats just me :) http://c2.com/xp/YouArentGonnaNeedIt.html Thanks update_seq does not always reflect the seq of the latest document update 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 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: 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=13173289#comment-13173289 ] Henrik Hofmeister commented on COUCHDB-1367: What i'm puzzled about - is what would i ever need the update_seq for ? It allows me to - see that there has been made a change - however in the changes view it shows me that there are no changes? Only in the cases where it differs for last_seq of course - but what could i ever possibly use that number for? That is - a number - signalling that i have either updated revs_limit or a random other number of internal api calls ? Its absolutly useless - especially while i have no way of getting to know whats changed. update_seq would - in any possible case - be expected by the user to reflect your core feature - the changes feed? Not making it into a huge problem - but the only real fix for a production env. product like couchdb is to not add to the confusion - but fix the confusion (like not adding another number to the db info page) . That would give you 2 numbers - one that is useless (update_seq) and one that is the one you'd expect (last_seq). ? 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] [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=13172296#comment-13172296 ] Henrik Hofmeister commented on COUCHDB-1367: No im not - i just made a script ensuring it gets set on all dbs - to save a request i did the just set it to 1 approach - assuming it wouldn't matter if i set it to 1 several times. This is how i discovered there was such a problem. We had been getting it randomly before - without ever realizing what the problem was exactly. Its true that this specific case is for couchdb-lucene - however the general use case of being able to predict how far you're away from being up to date is not couchdb-lucene specific - i've for one created another in-house application that does exactly this - while performing a chained map-reduce like operation (What im saying is - if you want to reap the benefits of the changes feed and be aware of your progress - you'll need the right number) 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
