You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@couchdb.apache.org by "Benjamin Anderson (JIRA)" <ji...@apache.org> on 2016/07/17 21:41:20 UTC

[jira] [Created] (COUCHDB-3063) Detangle "stale" mechanism in to component semantics

Benjamin Anderson created COUCHDB-3063:
------------------------------------------

             Summary: Detangle "stale" mechanism in to component semantics
                 Key: COUCHDB-3063
                 URL: https://issues.apache.org/jira/browse/COUCHDB-3063
             Project: CouchDB
          Issue Type: New Feature
            Reporter: Benjamin Anderson


The `stale` mechanism for view queries conflates two independent
concerns:

1. Whether or not the view results should be returned from a "stable"
   set of shards; i.e., mem3:ushards. This semantic is new in 2.0,
   having originated in Cloudant code in 2011[1].

2. Whether or not the view in question should be updated prior to
   responding to the user, i.e., the pre-2.0 semantics.

Both of these concerns represent consistency/availability tradeoffs, but
they're addressing rather different aspects of that continuum. As such,
the "stale" mechanism limits flexibility.

For example, it's quite likely that a user would want to retrieve
"stale" view responses from the fastest available shards - the
"available/available" choice - and this choice is not available with the
existing "stale" mechanism. A similar argument could be made for the
"consistent/consistent" choice.

[1]: https://github.com/apache/couchdb-fabric/commit/93923fda51c714c015b8621e41f3c425bfb3e61a



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)