-
Type:
Bug
-
Status: Closed
-
Priority:
Critical - P2
-
Resolution: Fixed
-
Affects Version/s: None
-
Component/s: Querying
-
Labels:
-
Backwards Compatibility:Fully Compatible
-
Operating System:ALL
-
Backport Requested:v4.0, v3.6, v3.4, v3.2
-
Steps To Reproduce:
-
Sprint:Query 2019-02-25
-
Linked BF Score:24
For a query like
{x: {$not: {$in: [["String"]]}} |
a collection scan will return the document
{x: "String"} |
because "String" != ["String"] and so "String" is not in the array [["String"]]. However, if you build an index on {x: 1} then the above document is not returned. Using explain, you can see the index bounds are:
{
|
"x" : [
|
"[MinKey, \"String\")",
|
"(\"String\", [ \"String\" ])",
|
"([ \"String\" ], MaxKey]"
|
]
|
}
|
Compare this to what should be the equivalent query
{x: {$ne: ["String"]}} |
we then get the bounds:
{
|
"x" : [
|
"[MinKey, [ \"String\" ])",
|
"([ \"String\" ], [ [ \"String\" ] ])",
|
"([ [ \"String\" ] ], MaxKey]"
|
]
|
}
|
It looks like the index bounds building logic for an $in within a $not.
- causes
-
SERVER-40691 $nin:[[],...] queries are not indexed
-
- Open
-
- related to
-
SERVER-39764 Negation of $in with embedded array can incorrectly plan from the cache, triggering invariant
-
- Closed
-