[SERVER-74298] Implement renaming by path component for PathMatchExpression Created: 23/Feb/23 Updated: 12/May/23 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Yoon Soo Kim | Assignee: | Backlog - Query Optimization |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Assigned Teams: |
Query Optimization
|
||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
|
While working on assuming that we have a pipeline like
the above $match should be able to be swapped with $project because $project is a simple rename. But as of today, there are two related issues to support the above match expression. 1) semantic_analysis::extractModifiedDependencies() reports the path 'x' as a modified dependency and call splitMatchExpressionBy(expr, fields = {"x"}, renames = {"x.y" -> "a.b"}) and hence the expr is not splittable and cannot be swapped with $project. We have the same issue for $elemMatch. Search for SERVER-74298 for more details on what to do. Also this note might be helpful. And also this analysis too: For example, {d: {$elemMatch: {e: 1, f: 1}} is transformed to the following tree:
And the DependencyVisitor reports only “d” as the dependency, neither “d.e” nor “d.f”. So, if “d.e” and “d.f” happen to be renamed paths from “a.b” and “a.c” by the previous $project stage, for example,
The $project reports renamed paths [\{d.e, a.b}, \{d.f, a.c}] but the DependencyVisitor only reports “d” as the dependency. So, we should not be able to rename “d.e” and “d.f” because “d” itself is neither a renamed nor preserved path and hence considered as a modified path by extractModifiedDependencies(). I noticed that “d.e” and “d.f” are also not renameable in the following example:
The {d: {e: 1, f: 1}} is transformed to the following tree:
Interestingly enough, {e: 1, f: 1} is not transformed to an $and expression at all. So, even though we have $elemMatch object expression renameable by sub path component, we would still have an issue with $eq match against an object. |