-
Type: Bug
-
Resolution: Done
-
Priority: Major - P3
-
Affects Version/s: 1.6.0
-
Component/s: None
-
None
-
Environment:CentOS, OSX
-
Linux
Ok, so we've found something that looks like it caused a lot of our production code to break.
We are running a nightly build (to fix the getMore issue) of 1.6.x. We have replica sets running with 3 replicas which act as a single shard. Only one shard is running, all others are not yet enabled. We have a users collection where documents have two main keys or paths:
1) "key" which is a string
2) "account" which is an object
We're running the following query* and an example result follows:
> db.users.find({},
{"key":1, "account":1}).skip(0).limit(50).sort(
{"account.created_at":-1});
{ "_id" : ObjectId("4c6062392b855c70fe65963b"), "account" :
, "key" : "xxxxxxxx" }
- please ignore the fact we don't have to use a separate created_at
Account has many other subkeys that are not visible in the result of the find.
Results of the explain query:
> db.users.find({},
).skip(0).limit(50).sort(
{"account.created_at":-1}).explain()
{
"clusteredType" : "ParallelSort",
"shards" : {
"chronotrigger/crono:10000,crono:10001,lucca:30000" : [
{
"cursor" : "BtreeCursor account.created_at_1 reverse",
"nscanned" : 194,
"nscannedObjects" : 194,
"n" : 193,
"millis" : 0,
"indexBounds" : {
"account.created_at" : [
[
,
{ "$minElement" : 1 } ]
]
}
}
]
},
"nscanned" : 194,
"nscannedObjects" : 194,
"n" : 193,
"millisTotal" : 0,
"millisAvg" : 0,
"numQueries" : 1,
"numShards" : 1
}
Interesting side case #1:
> db.users.find({},
{"key":1, "account.username":1}).skip(0).limit(50).sort(
{"account.created_at":1});
{ "_id" : ObjectId("4c5bbfb5f75364df46b5da1b"), "account" :
, "key" : "xxxxxx" }
Interesting side case #2:
> db.users.find({},
).skip(0).limit(50).sort({$natural:1});
-
- this returns what we were basically expecting but its sorted by _id time vs created_at time (which may actually differ in most rows)
Please let me know if additional information is needed. Thanks for your time.