[SERVER-43609] Consider applying FieldPath validation rules to MatchExpressions Created: 24/Sep/19 Updated: 06/Dec/22 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Querying |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Ian Boros | Assignee: | Backlog - Query Optimization |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Query Optimization
|
| Participants: |
| Description |
|
All paths used in aggregation use a single set of rules for validation, defined by our FieldPath class.
Paths used in the match language ($match and find()'s 'filter' argument) go through a different set of rules for validation, which are for the most part looser. Since these two languages interact (via dependency analysis of the $match stage), this has lead to some problems. For example, a user could refer to a field in a $match stage that's illegal to use elsewhere in aggregation (e.g. a $-prefixed field). This showed up in
We should consider making all paths used in match expressions follow the validation rules of FieldPath. This would bring us closer to a query language with a common set of rules about paths.
As a less radical alternative, we could also only apply FieldPath validation rules to match expressions used in a $match, though it may be harder to write.
It's worth noting that today these rules are enforced for $match in aggregation, but only because of the way we push down projections from DocumentSource to PlanStage (see here). This validation seems to happen "by accident" (it happens during an implicit constructor call here). |