-
Type: Improvement
-
Resolution: Duplicate
-
Priority: 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)
- duplicates
-
SERVER-30025 for sharded read with empty query, target only shards that own data for the collection instead of all shards
- Closed