[SERVER-30641] $expr should fail to parse if there are extra fields Created: 14/Aug/17 Updated: 27/Oct/23 Resolved: 07/Sep/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Querying |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Tess Avitabile (Inactive) | Assignee: | Backlog - Query Team (Inactive) |
| Resolution: | Gone away | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Query
|
| Operating System: | ALL |
| Participants: |
| Description |
|
Currently, when we are parsing a match expression, if we are in a position where there can be a $expr object, we will parse an object as a $expr if it contains exactly one field called $expr. Otherwise, it is treated as a literal object. However, this could cause an issue in the future if we add an additional option to $expr, say $option. Then in 3.6, we would parse {a: {$gt: {$expr: 5, $option: true}}} as comparison to the literal object {$expr: 5, $option: true}, but in 3.x, this would be treated as $expr with an option. Instead, in 3.6, we should fail to parse a $expr that has more than one field. |
| Comments |
| Comment by David Storch [ 07/Sep/17 ] |
|
This is no longer a problem due to the changes in |