[SERVER-29514] improve scatterGather() and establishCursors() interfaces around shard targeting policy Created: 08/Jun/17  Updated: 26/Sep/17  Resolved: 26/Sep/17

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: 3.5.8
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Esha Maharishi (Inactive) Assignee: Esha Maharishi (Inactive)
Resolution: Duplicate Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates SERVER-30025 for sharded read with empty query, ta... Closed
Participants:

 Description   

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)

Generated at Thu Feb 08 04:21:05 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.