Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-29514

improve scatterGather() and establishCursors() interfaces around shard targeting policy

    • Type: Icon: Improvement Improvement
    • Resolution: Duplicate
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: 3.5.8
    • Component/s: Sharding
    • None

      Both scatterGather() and establishCursors() should allow the caller to delegate deciding which shards to target and building versioned or unversioned requests to those shards.

      The caller should just specify a targeting policy (BroadcastToAllShards, UseRoutingTable, etc) and any additional options if relevant (e.g., target for a specific query when using the routing table).

      The current interface is muddled, and doesn't capture the range of targeting behavior used on mongos.

      Rather than allow lots of if/else blocks, boost::optional arguments, and re-implementations of targeting logic to sprawl across the codebase, we should succinctly express different types of shard targeting policies and the options that go with each, through a clearly differentiated set of functions or a set of classes.

      Some factors that determine a targeting policy and whether requests should be versioned:

      • whether the command has an associated collection
      • whether the associated collection is logically part of the routing table (as opposed to, say, $cmd or $aggregate)
      • whether the command is retryable (e.g., writes are currently not)

            Assignee:
            esha.maharishi@mongodb.com Esha Maharishi (Inactive)
            Reporter:
            esha.maharishi@mongodb.com Esha Maharishi (Inactive)
            Votes:
            1 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: