Re: [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
On Tue, Dec 20, 2011 at 7:39 AM, Robert Newson (Commented) (JIRA) wrote: > > [ > https://issues.apache.org/jira/browse/COUCHDB-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13172791#comment-13172791 > ] > > Robert Newson commented on COUCHDB-1367: > > > Oh, ye of little faith. couchdb-lucene certainly can handle the last_seq > output (and has since approximately forever). It's just so rarely encountered > that it doesn't help with respect to the issue at hand. First of all, faith is the most overrated virtue. It is, in fact, a vice. But no, sorry. I wasn't speaking about couchdb-lucene, but rather making a minor correction to Bob D.'s comment that a continuous listener hasn't access to the last_seq object. -- Iris Couch
[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-tabpanel&focusedCommentId=13172791#comment-13172791 ] Robert Newson commented on COUCHDB-1367: Oh, ye of little faith. couchdb-lucene certainly can handle the last_seq output (and has since approximately forever). It's just so rarely encountered that it doesn't help with respect to the issue at hand. > 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-tabpanel&focusedCommentId=13172752#comment-13172752
]
Jason Smith commented on COUCHDB-1367:
--
Hi, Bob. You said,
> couchdb-lucene uses continuous changes feeds so it doesn't have access to the
> last_seq value of a normal changes feed.
If the database is deleted during a continuous _changes request, CouchDB will
send {"last_seq":N} and disconnect the client. Perhaps it's not relevant to
this bug. But a robust changes listener should be prepared to get a last_seq
message.
I learned this from a bug report in Follow
https://github.com/iriscouch/follow/issues/6
> 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-tabpanel&focusedCommentId=13172432#comment-13172432 ] Paul Joseph Davis commented on COUCHDB-1367: Quite right. update_seq will be incremented for a number of API's that make changes while not updating documents. There's even an increment_update_seq API that just bumps it directly. Having a "last_update" in the db info blob that lists the last update for managing changes feeds might be useful in general and seems like it'd be an easy enough addition. > 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-tabpanel&focusedCommentId=13172401#comment-13172401 ] Bob Dionne commented on COUCHDB-1367: - sure, I think the confusion is this (from the WIKI): last_seq is the sequence number of the last update returned. (Currently it will always be the same as the seq of the last item in results.) It doesn't say that this is identical to update_seq. They are two different things, or at least became that way when other features such as set_revs_limit were added. It might be better for now in your app to use last_seq if you can > 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] [Resolved] (COUCHDB-1365) Fix merging of document with attachment stubs
[ https://issues.apache.org/jira/browse/COUCHDB-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Filipe Manana resolved COUCHDB-1365. Resolution: Fixed Assignee: Filipe Manana Fix applied to master, 1.2.x and 1.1.x branches. > Fix merging of document with attachment stubs > - > > Key: COUCHDB-1365 > URL: https://issues.apache.org/jira/browse/COUCHDB-1365 > Project: CouchDB > Issue Type: Bug > Components: Database Core, Replication >Reporter: Filipe Manana >Assignee: Filipe Manana >Priority: Blocker > Fix For: 1.2, 1.1.2 > > Attachments: > 0001-Fix-merging-of-documents-with-attachment-stubs.patch, > 0001-Fix-merging-of-documents-with-attachment-stubs.patch, > reproduce-CBMA-22.sh > > > This issue was found by Marty Schoch and is reproducible the following > attached script. > The commit message in the patch explains the issue: > "During replicated updates, merging of documents with > attachment stubs will fail if, after merging the received > document's revision tree with the current on disk revision > tree, produces a revision tree which doesn't contain the revision > that immediately precedes the received document's revision. > This happens when the received document doesn't contain in its > revision history any of the revisions in the revision tree > of the currently on disk document. This is possible when the > document had a number of updates higher than the value of revs > limit defined for the source database." -- 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-tabpanel&focusedCommentId=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
[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-tabpanel&focusedCommentId=13172245#comment-13172245 ] Bob Dionne commented on COUCHDB-1367: - Henrik, Thanks for the report. We discussed this a bit on irc this morning. So last_seq in the changes feed and update_seq in the db info are not intended to be the same, or at least there's some confusion about the semantics. couchdb-lucene uses continuous changes feeds so it doesn't have access to the last_seq value of a normal changes feed. When update_seq changes due to a call to set_revs_limit it gets out of whack. In any event the solution may be to simply add last_seq to the db_info record. It shouldn't be hard to fix and as you say this is an edge case. I'm curious are you setting the revs_limit a lot? If so what's the use case? Bob > 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] [Assigned] (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 ] Bob Dionne reassigned COUCHDB-1367: --- Assignee: Bob Dionne > 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
