[SERVER-70119] Document usage of TenantId for Storage Execution Created: 29/Sep/22  Updated: 23/Jan/24  Resolved: 23/Jan/24

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

Type: Task Priority: Major - P3
Reporter: Dianna Hohensee (Inactive) Assignee: Backlog - Service Architecture
Resolution: Duplicate Votes: 0
Labels: ntdi_must_have
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates SERVER-57961 Architecture Guide updates for PM-2346 Open
Related
related to SERVER-57961 Architecture Guide updates for PM-2346 Open
related to SERVER-68267 Implement function to search for dura... Closed
Assigned Teams:
Service Arch
Sprint: Server Serverless 2023-08-21
Participants:
Story Points: 3

 Description   

The toString() methods on DatabaseName and NamespaceString do not include the tenantId. We usually deal with a namespace as db.coll. However, in the __mdb_catalog entries, and the per database views collection catalog entries, namespace is now <tenantId>_db.coll. It's important that this is clearly documented so that new persisted data access methods that are written in future take into account the specially parsing needed to reconstruct the NamespaceString from persisted state; also for namespace comparison.

Documentation points would be class level, and the architecture guide.



 Comments   
Comment by Didier Nadeau [ 23/Jan/24 ]

This documentation should be included in the larger arch guide to be created for NTDI.

Comment by Janna Golden [ 17/Oct/22 ]

Okay sounds good, I'll pull this ticket into our project so we'll get to it before closing it out. Thanks dianna.hohensee@mongodb.com!

Comment by Dianna Hohensee (Inactive) [ 14/Oct/22 ]

My thoughts were

1) an addition to the storage execution architecture guide – probably add/modify this section to include the new information.
2) and probably calls to NamespaceString::parseFromStringExpectTenantIdInMultitenancyMode & toStringWithTenantId() in the DurableCatalogImpl should have descriptive in-line comments
3) the durable_catalog.h header file should also generally be more informative about what the execution catalog looks like in persisted form: DurableCatalog has little documentation. That's something storage execution should handle, as it's our tech-debt I think, but also this new information needs to go someplace.

On further thought, _addEntry and _replaceEntry logic handling around toStringWithTenantId and general entry construction can probably be refactored so the code and new comments aren't duplicated as much. The DurableCatalogImpl code looks generally ripe for tightening up the code some at this point. But again, I think that's a storage execution problem, not serverless.

Comment by Fausto Leyva (Inactive) [ 11/Oct/22 ]

CC: dianna.hohensee@mongodb.com 

Generated at Thu Feb 08 06:15:19 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.