[ https://issues.apache.org/jira/browse/COUCHDB-3063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15552944#comment-15552944 ]
ASF subversion and git services commented on COUCHDB-3063: ---------------------------------------------------------- Commit 459a548f269b00bf2d2ace0170c583e72fde4cb9 in couchdb-couch-mrview's branch refs/heads/master from [~banjiewen] [ https://git-wip-us.apache.org/repos/asf?p=couchdb-couch-mrview.git;h=459a548 ] 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)