[jira] [Updated] (COUCHDB-1367) update_seq does not always reflect the seq of the latest document update

["Randall Leeds (Updated) (JIRA)" <ji...@apache.org>]

     [ 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