[SERVER-4336] range queries against an indexed field within an array ignores the upper (or lower) bound Created: 21/Nov/11  Updated: 07/Mar/14  Resolved: 21/Nov/11

Status: Closed
Project: Core Server
Component/s: Querying
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Andrew Harbick Assignee: Aaron Staple
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Operating System: ALL
Participants:

 Description   

See: http://groups.google.com/group/mongodb-user/browse_thread/thread/7a67b122e4bf495a

I don't know if this a feature of multikeys or what but it seems wrong...

Imagine I have a collection with documents that look like this:

{
name: "Test"
details: [

{ timestamp: 1319083200000, type: "something" }

,

{ timestamp: 1320083200000, type: "something else" }

]
}

These commands will create one of those documents, index it, and then explain a query:

db.testdocuments.insert({name: "Test", details: [

{timestamp: 1319083200000, type: "something"}

,

{timestamp: 1320083200000, type: "something else"}

]})
db.testdocuments.ensureIndex(

{"details.timestamp": 1}

)
db.testdocuments.find({'details.timestamp': {$gte:
1319083200000, $lte: 1319093200000}}).explain()
{
"cursor" : "BtreeCursor details.timestamp_1",
"nscanned" : 404081,
"nscannedObjects" : 404081,
"n" : 3494,
"millis" : 3063,
"nYields" : 455,
"nChunkSkips" : 0,
"isMultiKey" : true,
"indexOnly" : false,
"indexBounds" :

{ "details.timestamp" : [ [ 1319083200000, 1.7976931348623157e+308 ] ] }


}

NOTE the upper bound is messed up...

If I do a descending index the lower bound is messed up.

Also, note that if you create a document that only has one element in the details array the index bounds are correct.



 Comments   
Comment by Aaron Staple [ 21/Nov/11 ]

Yep, I think it's a duplicate of SERVER-4180.

Comment by Andrew Harbick [ 21/Nov/11 ]

Looks like this is a duplicate of https://jira.mongodb.org/browse/SERVER-4180

Generated at Thu Feb 08 03:05:41 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.