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

["Robert Newson (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/COUCHDB-3063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Robert Newson resolved COUCHDB-3063.
------------------------------------
       Resolution: Fixed
    Fix Version/s: 2.1.0

> 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
>            Priority: Minor
>             Fix For: 2.1.0
>
>
> 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)