Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-43609

Consider applying FieldPath validation rules to MatchExpressions

    • Type: Icon: Improvement Improvement
    • Resolution: Unresolved
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: Querying
    • Labels:
      None
    • Query Optimization

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

            Assignee:
            backlog-query-optimization [DO NOT USE] Backlog - Query Optimization
            Reporter:
            ian.boros@mongodb.com Ian Boros
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated: