-
Type: Improvement
-
Resolution: Unresolved
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
Catalog and Routing
-
CAR Team 2024-10-28, CAR Team 2024-11-11, CAR Team 2024-11-25
(Subtask to achieve SERVER-84243 - Dedicate a catalog cache and loader to the shard role. For more information refer to this document)
Today, FilteringMetadataCache has a shared_ptr<CatalogCacheLoader> as member of the class, representing the ShardServerCatalogCacheLoader implementation, but accepting the injection of the CatalogCacheLoaderMock (testing purposes) or the ReadOnlyCatalogCacheLoader (queryableBackupMode).
This implies having some dynamic cast - from the loader pointer to ShardServerCatalogCacheLoader - to use some of the methods only implemented by the last.
The goal of this ticket is to create a better architecture, by creating a new interface that implements all the necessary methods that the FilteringMetadataCache’s loader needs, consequently removing all the dynamic casts, and breaking the dependency of the pareten interface CatalogCacheLoader.
Therefore, today:
- CatalogCacheLoader (Interface)
- ConfigServerCatalogCacheLoader
- ShardServerCatalogCacheLoader
- ReadOnlyCatalogCacheLoader
- CatalogCacheLoaderMock
The proposed architecture is:
- ConfigServerCatalogCacheLoader (Interface)
- ConfigServerCatalogCacheLoaderImpl
- ConfigServerCatalogCacheLoaderMock
- ShardServerCatalogCacheLoader (Interface) -> deprecated once shards are authoritative
- ShardServerCatalogCacheLoaderImpl
- ReadOnlyCatalogCacheLoader
- ShardServerCatalogCacheLoaderMock
Open question: Do we want to rename the ShardServerCatalogCacheLoader and ConfigServerCatalogCacheLoader to RouterRoleCatalogCacheLoader and ShardRoleCatalogCacheLoader?
- depends on
-
SERVER-95393 Use a ConfigServerCatalogCacheLoader for the router-role and a ShardServerCatalogCacheLoader for the shard-role
- In Progress