[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: |
|
||||||||||||||||||||
| 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. 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 ] |