As of the changes in SERVER-19402, a multikey field of an index cannot be used to provide a non-blocking sort. This is not correctly enforced in the explodeForSort() path of the planner's sort analysis phase. As a result, the planner produces an incorrect plan which does not sort array fields correctly according to the new semantics described in SERVER-19402:
> db.c.find();
{ "_id" : 0, "a" : [ { "b" : 0, "c" : 1 }, { "b" : 1, "c" : 2 } ] }
{ "_id" : 1, "a" : [ { "b" : 0, "c" : 2 }, { "b" : 1, "c" : 0 } ] }
{ "_id" : 2, "a" : [ { "b" : 0, "c" : 0 }, { "b" : 1, "c" : 1 } ] }
> db.c.createIndex({"a.b": 1, "a.c": 1})
{
"createdCollectionAutomatically" : false,
"numIndexesBefore" : 2,
"numIndexesAfter" : 2,
"note" : "all indexes already exist",
"ok" : 1
}
// The sort order is incorrect since the _id:1 document should sort before _id:0.
> db.c.find({"a.b": 0 }).sort({"a.c": 1 });
{ "_id" : 2, "a" : [ { "b" : 0, "c" : 0 }, { "b" : 1, "c" : 1 } ] }
{ "_id" : 0, "a" : [ { "b" : 0, "c" : 1 }, { "b" : 1, "c" : 2 } ] }
{ "_id" : 1, "a" : [ { "b" : 0, "c" : 2 }, { "b" : 1, "c" : 0 } ] }
- is related to
-
SERVER-19402 Change semantics of sorting by array fields in find and aggregate
-
- Closed
-