Uploaded image for project: 'CouchDB'
  1. CouchDB
  2. COUCHDB-3063

Detangle "stale" mechanism in to component semantics

    Details

    • Type: New Feature
    • Status: Resolved
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.1.0
    • Component/s: None
    • Labels:
      None

      Description

      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

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              banjiewen Benjamin Anderson
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: