couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Randall Leeds (Updated) (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (COUCHDB-1367) update_seq does not always reflect the seq of the latest document update
Date Fri, 30 Dec 2011 20:12:30 GMT

     [ 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

        

Mime
View raw message