Details
-
Bug
-
Status: Closed
-
Major - P3
-
Resolution: Fixed
-
4.2.0, 4.4.0
-
None
-
Fully Compatible
-
ALL
-
v4.4, v4.2
-
Query 2020-11-30, Query 2020-12-14
Description
Getting the namespace involved in a cross-database $merge stage causes the StringMap<ResolvedNamespace> to store a key for the target collection name with an empty pipeline. But that collection name may also be the name for a collection or view in the database the aggregate command is being run against. For certain pipelines, this may cause a $lookup on a view to instead act as if it were performing the $lookup on an empty collection without erroring.
if (involvedNs.db() != request.getNamespaceString().db()) { |
// If the involved namespace is not in the same database as the aggregation, it must be |
// from a $merge to a collection in a different database. Since we cannot write to |
// views, simply assume that the namespace is a collection. |
resolvedNamespaces[involvedNs.coll()] = {involvedNs, std::vector<BSONObj>{}};
|
Note that because LiteParsedPipeline::getInvolvedNamespaces() returns a stdx::unordered_set<NamespaceString> that namespaces may be resolved in different orders across multiple aggregate command executions. And also note that because resolveInvolvedNamespaces() skips resolving a namespace if its collection name already exists in the StringMap, this issue would only manifest if the $merge namespace was resolved before the $lookup namespace.
Attachments
Issue Links
- is related to
-
SERVER-13201 Allow new Aggregation $merge stage to explicitly name a DB to write to
-
- Closed
-