[SERVER-2620] Multi-key indexes on arrays of object with more than one key cause queries to behave like $elemMatch by default. Created: 24/Feb/11  Updated: 29/May/12  Resolved: 07/Jun/11

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

Type: Bug Priority: Major - P3
Reporter: Kyle Banker 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   

Attempting to index and query a set of dynamic attributes, I seem to have encountered a bug.

> db.foo.save({attrs: [

{n: "low", v: 100}

,

{n: "high", v: 100}

]})
> db.foo.save({attrs: [

{n: "low", v: 200}

,

{n: "high", v: 500}

]})
> db.foo.find(

{"attrs.n": "low", "attrs.v": 500}

)
{ "_id" : ObjectId("4d66b232d6eb5559fa645ce2"), "attrs" : [

{ "n" : "low", "v" : 200 }

,

{ "n" : "high", "v" : 500 }

] }

Now we add an index, and this returns nothing:

> db.foo.ensureIndex(

{"attrs.n": 1, "attrs.v": 1}

)
> db.foo.find(

{"attrs.n": "low", "attrs.v": 500}

)
(Returns nothing)

Shouldn't the behavior be the same with the index in place?

However. A query matching a complete object with the document work with the index:
> db.foo.find(

{"attrs.n": "low", "attrs.v": 200}

)
{ "_id" : ObjectId("4d66b232d6eb5559fa645ce2"), "attrs" : [

{ "n" : "low", "v" : 200 }

,

{ "n" : "high", "v" : 500 }

] }

And seems to be doing the equivalent of an $elemMatch:
> db.foo.find({attrs: {$elemMatch:

{n: "low", v: 100}

}})
{ "_id" : ObjectId("4d66b227d6eb5559fa645ce1"), "attrs" : [

{ "n" : "low", "v" : 100 }

,

{ "n" : "high", "v" : 100 }

] }

Is this the expected behavior?



 Comments   
Comment by Aaron Staple [ 07/Jun/11 ]

This was fixed as part of the SERVER-958 work.

Comment by Jakub Suder [ 04/Mar/11 ]

I also found this issue... I have a "profiles" collection with "services" field and the services have "type" and "username" fields. I was trying to show another developer that he needs to use $elemMatch to look for services with type and username, otherwise he may find a profile whose one service matches type and another service matches username. Turns out, it didn't work... and I found that this is because of an index we have on profiles on [services.type, services.username].

On the wiki there is an example that explains why $elemMatch should be necessary in this case: http://www.mongodb.org/display/DOCS/Dot+Notation+(Reaching+into+Objects)

Now, if I create the two records from the example:

> db.foo.save({ foo: [

{ shape: "square", color: "purple", thick: false }

,

{ shape: "circle", color: "red", thick: true }

] })
> db.foo.save({ foo: [

{ shape: "square", color: "red", thick: true }

,

{ shape: "circle", color: "purple", thick: false }

] })

And then search:

> db.foo.find(

{ "foo.shape": "square", "foo.color": "purple" }

)

I get two records. But if I add an index and then search again:

> db.foo.ensureIndex(

{ "foo.shape": 1, "foo.color": 1 }

)
> db.foo.find(

{ "foo.shape": "square", "foo.color": "purple" }

)

Then I get only one record (the first one). And if for some reason the index isn't used, even though it exists (perhaps because another index is used):

> db.foo.find(

{ "foo.shape": "square", "foo.color": "purple" }

).hint(

{ $natural: 1 }

)

Then you still get 2 records... So the result may be that the algorithm for matching is different depending on whether an index is used or not, and you can't always know which index will be used, so your system may behave a bit non-deterministically... I'd say such kind of behavior is a bug.

Comment by Eliot Horowitz (Inactive) [ 25/Feb/11 ]

Actually creating that index should fail as your'e really doing an N^2 index.

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