[
https://issues.apache.org/jira/browse/COUCHDB-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Randall Leeds updated COUCHDB-1367:
-----------------------------------
Description: 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. (was: 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. )
Summary: update_seq does not always reflect the seq of the latest
document update (was: When settings revs_limit on db - the db increases its
update_seq counter when viewing stats - but not when getting changes)
Updated the description and title to reflect the problem in general.
Proposals so far:
1. Add a new header field
a. to track the highest value in the by_seq index
b. to track header updates that do not affect by_seq, causing update_seq to
behave in a manner more consistent with expectation
2. Migrate the non-replicable metadata into the document API and hang it within
the by_seq index
As far as I can tell I'm the only proponent of (2). Proposal (2) is broader in
scope, more difficult to implement, and fails to account for the possibility
that other, current or future, database header updates may not fit into the
document model. Therefore, I'll formally retract my suggestion that it be
pursued as a solution to the present ticket.
Resuming discussion back here (sorry if it was unnecessary or confusing that I
migrated it to dev@), how does the community feel about (1a) vs (1b)? I'm in
favor of 1b, myself.
> 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
