[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}]}) , {n: "high", v: 500}]}) ) , { "n" : "high", "v" : 500 }] } Now we add an index, and this returns nothing: > db.foo.ensureIndex( {"attrs.n": 1, "attrs.v": 1}) ) 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: ) , { "n" : "high", "v" : 500 }] } And seems to be doing the equivalent of an $elemMatch: }}) , { "n" : "high", "v" : 100 }] } Is this the expected behavior? |
| Comments |
| Comment by Aaron Staple [ 07/Jun/11 ] |
|
This was fixed as part of the |
| 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 } ] }) , { 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 }) ) 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. |