[
https://issues.apache.org/jira/browse/COUCHDB-3063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15381529#comment-15381529
]
ASF GitHub Bot commented on COUCHDB-3063:
-----------------------------------------
GitHub user banjiewen opened a pull request:
https://github.com/apache/couchdb-couch-mrview/pull/51
Replace `stale` with `stable` and `update`
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.
This patch introduces two new view API keywords - "stable" and "update"
- to address concerns #1 and #2, respectively. The semantics of the
"stale" mechanism is implemented in terms of these new keywords.
COUCHDB-3063
[1]: apache/couchdb-fabric@93923fda51c714c015b8621e41f3c425bfb3e61a
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/banjiewen/couchdb-couch-mrview
stale-stable-update
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/couchdb-couch-mrview/pull/51.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #51
----
commit 459a548f269b00bf2d2ace0170c583e72fde4cb9
Author: Benjamin Anderson <b...@banjiewen.net>
Date: 2016-07-17T21:25:22Z
Replace `stale` with `stable` and `update`
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.
This patch introduces two new view API keywords - "stable" and "update"
- to address concerns #1 and #2, respectively. The semantics of the
"stale" mechanism is implemented in terms of these new keywords.
COUCHDB-3063
[1]: apache/couchdb-fabric@93923fda51c714c015b8621e41f3c425bfb3e61a
----
> 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
>
> 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)
