[SERVER-63401] Audit callers of IndexAccessMethod::asSortedData() Created: 08/Feb/22  Updated: 19/May/22  Resolved: 18/May/22

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

Type: Task Priority: Major - P3
Reporter: Mathias Stearn Assignee: Henrik Edin
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Sprint: Execution Team 2022-04-04, Execution Team 2022-04-18, Execution Team 2022-05-02, Execution Team 2022-05-16, Execution Team 2022-05-30
Participants:

 Description   

As part of SERVER-63251, I moved all of the SortedData specific functionality from IndexAccessMethod down to SortedDataIndexAccessMethod. Callers that use that functionality make use of a named down-cast method called asSortedData(). That is fine for now since all indexes are still based on SortedData, however that won't be true for very long. We will need to audit all callers to verify if they are only expected to work with SortedData-based indexes or if they are intended to work with any kind of index. Non-exhaustive list of examples:

  • SortedData-specific:
    • All query stages that access existing indexes (non-SortedData indexes will use different query stages)
    • Everything related to multikey and uniqueness (at least for now, these are SortedData-specific things)
    • Anything that is specific to the _id index (it needs to be SortedData)
  • General:
    • Everything related to validation
  • Somewhat in between (these are SortedData-specific, but we will probably want something similar for other index kinds):
    • IndexBuildIntercepter
    • SortedDataInterfaceThrottleCursor

We won't need to consider any calls from C++ test code since tests control which indexes they create and won't suddenly start needing to work with other types of indexes. However, we may want to do a pass to see if the test is trying to test something that we where would want coverage for non-SortedData indexes.


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