-
Type:
Improvement
-
Resolution: Unresolved
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
Query Integration
-
None
-
0
-
None
-
None
-
None
-
None
-
None
-
None
The ExpressionContext holds information about a bunch of different namespaces, like the user-provided namespace, the execution namespace, and any secondary involved namespaces. Reading the code, the distinction between each of those members is not clear. This ticket should improve this.
------------------------------
More details:
The resolved namespaces stored on the ExpressionContext are intended to hold information about the secondary namespaces involved in a query (for example, namespaces of $lookup or $unionWith subpipelines) but not the primary namespace. This is particularly evident by this function:
bool noForeignNamespaces() const { return _params.resolvedNamespaces.empty(); }
Elsewhere, that distinction is not clear. The code and surrounding documentation should be improved to make that obvious to readers.
Additionally, it would be helpful to change ns in ExpressionContext to be executionNss to better represent what the member variable holds. Please note that making this change in both ExpressionContext and ExpressionContextBuilder requires trivial updates in ~100 files (i.e. will require a lot of reviews across teams).
- is related to
-
SERVER-103684 Add separate API to ExpressionContext to hold view's ResolvedNamespace
-
- Closed
-
-
SERVER-103886 Investigate consolidating SearchQueryViewSpec with ResolvedView and/or ResolvedNamespace
-
- Backlog
-