[SERVER-1454] Use $not as a top-level logical op Created: 21/Jul/10 Updated: 06/Dec/22 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Querying |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | New Feature | Priority: | Trivial - P5 |
| Reporter: | Steve Wagner | Assignee: | Backlog - Query Optimization |
| Resolution: | Unresolved | Votes: | 17 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||||||||||||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||
| Assigned Teams: |
Query Optimization
|
||||||||||||||||||||||||||||||||||||
| Backport Requested: |
v4.4, v4.2, v4.0
|
||||||||||||||||||||||||||||||||||||
| Sprint: | Query Optimization 2021-06-14, QO 2021-09-20, QO 2021-10-04, QO 2021-10-18, QO 2021-11-01, QO 2021-11-15, QO 2021-11-29, QO 2021-12-13, QO 2021-12-27, QO 2022-01-10, QO 2022-01-24, QO 2022-02-07, QO 2022-02-21, QO 2022-03-07 | ||||||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||||||
| Case: | (copied to CRM) | ||||||||||||||||||||||||||||||||||||
| Description |
|
In our MongoDB-CSharp driver we convert code expressions like that to documents queries.
The problem here is that the ! operator reverses the meaning of both equality checks. This scenario would be much easier to accomplish when we could use the $not operator like the $or operator. Example:
I think also that this is more the way the users expect to use the $not operator. |
| Comments |
| Comment by Steve La (Inactive) [ 11/Dec/21 ] | ||||||
|
Hi Joe Thx | ||||||
| Comment by Timour Katchaounov [ 11/Mar/21 ] | ||||||
|
A WIP code review. | ||||||
| Comment by Charlie Swanson [ 24/Feb/21 ] | ||||||
|
I uploaded top_level_not.patch
into a MatchExpression tree with NOT -> GT(x, 4). Then it has to extract the "x" and serialize back to the original. So there's some finicky code to try to search within a $not sub-tree to find the path. All of that can probably be removed if we allow $not to be top-level. I would proceed with caution here because it's been a source of some bugs. I'm not sure why we didn't just allow this syntax for It could be related to upgrade/downgrade concerns. If we start serializing in a new format, we need to make sure everyone in the cluster understands that format. For mongos this shouldn't be a problem because mongos is the last to be upgraded, but we do send queries from shard to shard for cases like $merge. In these cases we'll need to make sure we're on the upgraded FCV before using the new serialization format - which would cause us to keep around the old serialization code, at least for one major release. | ||||||
| Comment by Charlie Swanson [ 09/Feb/21 ] | ||||||
|
I'm nominating this as quick win because I have no reason to suspect it's all that hard and it would simplify some of the language building efforts on the drivers side. | ||||||
| Comment by Asya Kamsky [ 15/Apr/16 ] | ||||||
|
Equivalent of top level $not that already works now would be {$nor: [ { original-query } ] } | ||||||
| Comment by Eugen M [ 17/Dec/15 ] | ||||||
|
To Robert Stam: For MongoDB-developers, I think, the ambiguity or complexity would not be at all. Since they will only take those objects that do not fall under a set of conditions shown in $ not: {}. | ||||||
| Comment by Eugen M [ 17/Dec/15 ] | ||||||
|
it will be a very good feature! PS in my example i need to ADD ALL FIELDS in project! Automotically it imposible and i use "fields: "$$ROOT"", then i need to exclude this new level (named "fields").... This is unnormal way! ( | ||||||
| Comment by Robert Stam [ 07/Apr/15 ] | ||||||
|
I think $not should take a single argument, otherwise it can be rather ambiguous what it means (does De Morgan's Law apply or not?). The example in the description could be represented unambiguously as:
| ||||||
| Comment by Nathan Ehresman [ 30/Dec/10 ] | ||||||
|
I have a situation where expanded $not support would be very useful. We have a query builder to let the user build complex expressions that are then translated into a MongoDB query and executed. | ||||||
| Comment by Eliot Horowitz (Inactive) [ 21/Jul/10 ] | ||||||
|
When we prioritize this will depend on # of votes primarily. | ||||||
| Comment by Steve Wagner [ 21/Jul/10 ] | ||||||
|
I would really like to know if you consider adding this or not soon. |