[SERVER-54401] Move shard filtering metadata out of the query layer and into the new CollectionPtr class Created: 08/Feb/21  Updated: 06/Dec/22  Resolved: 17/Feb/22

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

Type: Improvement Priority: Major - P3
Reporter: Dianna Hohensee (Inactive) Assignee: [DO NOT USE] Backlog - Sharding EMEA
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
Problem/Incident
is caused by SERVER-53257 Determine whether we need const Colle... Closed
Assigned Teams:
Sharding EMEA
Participants:

 Description   

The shard filtering/routing information should be moved from the query layer to the AutoGetCollection*/CollectionPtr interfaces

  • With this change, we should reconsider whether the AutoGetCollection* classes still need to explicitly check the shardVersion, as fetching the filtering metadata does the check implicitly.
  • ScopedCollectionDescription, or whatever class is the filtering metadata, must not have any other sharding linking dependencies, and should be documented strongly to keep it that way. We do NOT want to link sharding into the execution catalog / code layer.

----------------------------------------------------------------------------------------------------

The new CollectionPtr accessible via the AutoGetCollection* collection helpers are passed throughout the code (replacing how we used to pass raw Collection pointers). The query code has access to the CollectionPtr, so placing the shard filtering metadata on the CollectionPtr during AutoGetCollection* setup would provide query code access.


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