[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 SERVER-39109 (a server crasher).

 

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).


Generated at Thu Feb 08 05:03:36 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.