-
Notifications
You must be signed in to change notification settings - Fork 72
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
Comments
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.
Would produce an index with a hash map like this:
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:
Then a lookup against the map by doing:
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. |
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 :) |
Gave it a try, fixed 👍 |
Will break future queries on a single key, like:
P.S
Does not seem to be the same bug as #27
The text was updated successfully, but these errors were encountered: