-
Type:
Improvement
-
Resolution: Won't Fix
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
Server Programmability
From a recent code review for SERVER-77348:
The way I see it, there should be only the following ways to ask for a namespace and either it should be just 1 or all, but not some combination of the three:
Either I give you the namespace (db.coll) and I don't care what's behind, which should be 99% of the cases
OR I give you the DB+UUID and I don't care what's the name
OR I give you all of the above and I want them all to match
There are a few places where we track an optional nss, dbName, and uuid, which look deceptively similar to a NamespaceStringOrUUID. We should consider introducing a new type to express the case that NamespaceStringOrUUID cannot currently handle: NamespaceString and UUID. Another choice might be to support a third state in the NamespaceStringOrUUID union (and perhaps rename that type to something like CollectionOrViewLocator).
Examples:
- https://github.com/mongodb/mongo/blob/a1776917bebc14c1ba822480c63f55d3af7b2804/src/mongo/db/shard_role.h#L91-L94
- https://github.com/mongodb/mongo/blob/aaf8464c54244781177f57f341f59a324bac39ca/src/mongo/db/pipeline/expression_context.h#L470-L475
- https://github.com/mongodb/mongo/blob/aaf8464c54244781177f57f341f59a324bac39ca/src/mongo/db/catalog/uncommitted_catalog_updates.h#L351-L352
- related to
-
SERVER-96002 Complete TODO listed in SERVER-78226
-
- Backlog
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-