[SERVER-30731] Add $expr support in MatchExpression outside of aggregation Created: 18/Aug/17  Updated: 30/Oct/23  Resolved: 05/Oct/17

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 3.6.0-rc0

Type: Task Priority: Major - P3
Reporter: James Wahlin Assignee: Tess Avitabile (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Documented
is documented by DOCS-10787 Docs for SERVER-30951: Add top-level ... Closed
is documented by DOCS-10880 Docs for SERVER-30731: Add $expr supp... Closed
Duplicate
is duplicated by SERVER-31365 Reject $jsonSchema within a $pull ope... Closed
is duplicated by SERVER-7623 comparison operation right hand side ... Closed
is duplicated by SERVER-2702 Compare document fields in queries Closed
is duplicated by SERVER-31201 JSON Schema inside an arrayFilter sho... Closed
is duplicated by SERVER-9366 Expose projection (aggregation) opera... Closed
Related
is related to SERVER-7623 comparison operation right hand side ... Closed
Backwards Compatibility: Fully Compatible
Sprint: Query 2017-10-02, Query 2017-10-23
Participants:

 Description   

All commands that contain MatchExpression filters should support with the exception of partialFilterExpression and upsert which we will ban.



 Comments   
Comment by Githook User [ 05/Oct/17 ]

Author:

{'email': 'tess.avitabile@mongodb.com', 'name': 'Tess Avitabile', 'username': 'tessavitabile'}

Message: SERVER-30731 Add expr support in MatchExpression outside of aggregation
Branch: master
https://github.com/mongodb/mongo/commit/cb9f7cdcb7eb6ad9077ac8af3a4c0d7275c7e34f

Comment by Githook User [ 05/Oct/17 ]

Author:

{'email': 'tess.avitabile@mongodb.com', 'name': 'Tess Avitabile', 'username': 'tessavitabile'}

Message: SERVER-30731 Add expr support in MatchExpression outside of aggregation
Branch: master
https://github.com/10gen/mongo-enterprise-modules/commit/7896809e621b7b50db9a83d6ad90f9dd6919778b

Comment by Tess Avitabile (Inactive) [ 29/Sep/17 ]

Moving this ticket back to the In Progress state to work on the second part: enable $expr outside of aggregation.

Comment by Githook User [ 29/Sep/17 ]

Author:

{'email': 'tess.avitabile@mongodb.com', 'name': 'Tess Avitabile', 'username': 'tessavitabile'}

Message: SERVER-30731 MatchExpressionParser::parse() should require an ExpressionContext
Branch: master
https://github.com/10gen/mongo-enterprise-modules/commit/c0c692488ee1308f7f83cc2eba872f03ea0cbbb0

Comment by Githook User [ 29/Sep/17 ]

Author:

{'email': 'tess.avitabile@mongodb.com', 'name': 'Tess Avitabile', 'username': 'tessavitabile'}

Message: SERVER-30731 MatchExpressionParser::parse() should require an ExpressionContext
Branch: master
https://github.com/mongodb/mongo/commit/e0a505e2a8bfe59d8bdfc4e5a25aef4861d58fcf

Comment by Tess Avitabile (Inactive) [ 07/Sep/17 ]

Re (1): Sounds good.

Re (2): Ah, I see, ExprMatchExpression wants a const boost::intrusive_ptr<ExpressionContext>&, so MatchExpressionParser::parse() should continue to take a const boost::intrusive_ptr<ExpressionContext>&. However, it will require it to be non-null.

Re (3): No. For MatchExpressions that require a collator, the MatchExpressionParser will continue to pass them a CollatorInterface*, which it will get from its passed in expCtx.

Comment by James Wahlin [ 07/Sep/17 ]

Overall this sounds good. I have a few thoughts / questions:

  1. The new ExpressionContext class should also contain a 'VariablesParseState' member.
  2. The ExpressionContext's Variables instance may be modified by ExprMatchExpression while evaluating ExpressionLet (see here) so we shouldn't pass as const reference, unless we plan to make a copy.
  3. Will this change the mechanism used to change a MatchExpression's collator?
Comment by Tess Avitabile (Inactive) [ 07/Sep/17 ]

james.wahlin, david.storch, my plan is to do this in two commits.

First commit:
Rename ExpressionContext to AggregationContext. Create an ExpressionContext class that contains only a CollatorInterface* and a Variables. AggregationContext will have a protected ExpressionContext and std::unique_ptr<CollatorInterface>, where it owns its collator. It will still expose getCollator(), and it will also expose getExpressionContext() instead of variables. MatchExpressionParser::parse() will take a single const ExpressionContext& instead of a const CollatorInterface* and a const boost::intrusive_ptr<ExpressionContext>&.

Second commit:
MatchExpressionParser::parse() allows $expr by default. Ban $expr in partialFilterExpression, upserts, and the group command. Add tests for places $expr is allowed and disallowed.

How does this sound?

Generated at Thu Feb 08 04:24:49 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.