Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ensureIndex() on multiple indices breaks future queries on the collection #28

Closed
aabluedragon opened this issue Feb 17, 2015 · 3 comments

Comments

@aabluedragon
Copy link

myCollection.ensureIndex({
    business_id: 1,
    id: 1
});

Will break future queries on a single key, like:

myCollection.find({business_id:1});

P.S
Does not seem to be the same bug as #27

@Irrelon
Copy link
Owner

Irrelon commented Feb 18, 2015

This is caused by the way the query analyser determines if an index should be used or not based on the keys being queried. At present indexes are simply hash maps with a hash built from the keys that are indexed so a collection with an index on business_id and business_name will have a hash that concatenates those values from the object being indexed e.g.

{ business_id: '1', business_name: 'apple' }

Would produce an index with a hash map like this:

{
    "1_apple":[{
        business_id: '1',
        business_name: 'apple'
    }]
}

The index stores the keys that were indexed and when a query is run against the index it will return results based on the hash generated from the keys of the query. The bug is in the analyser because it determines that if at least one key in the query matches the index that it should be used for a quick lookup but that is a false assumption. It would be correct if the index was a tree structure because it could be traversed and data pulled at the point the keys intersect but because the indexes are currently limited to hash maps the hash from the query you specified in your example would be:

"1"

Then a lookup against the map by doing:

return this.hashMap["1"];

Would return no results because the entire hash to bring back the result would have to be used, not a partial e.g. "1_apple" rather than "1".

At present there is a quick fix in that the query analyser can be altered to ensure that it does not use a query where only one of the keys in an index is used. This is not ideal but fixes the bug in that results will actually be returned.

The issue about matching data based on single key queries in a multi-key index can be solved using a tree structure instead of a hash map but that is more of a new feature than a bug fix :)

I'll keep this issue open and update when the bug is resolved shortly.

Irrelon added a commit that referenced this issue Feb 18, 2015
@Irrelon
Copy link
Owner

Irrelon commented Feb 18, 2015

Fix to this is in dev branch version 1.3.1 - if you could give it a try and test against your issue that would be great :)

@aabluedragon
Copy link
Author

Gave it a try, fixed 👍
Thanks!

@Irrelon Irrelon closed this as completed Feb 20, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants