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

Fix incorrect indexable_fields for $in #752

Merged
merged 1 commit into from Aug 15, 2017

Conversation

Projects
None yet
3 participants
@tonysun83
Contributor

tonysun83 commented Aug 15, 2017

Overview

The function indexable_fields/1 is supposed to remove extraneous fields
created by the mango_selector_text:convert/1 function so that indexes
will not be bypassed during index selection time. This wasn't working
as expected in the case of $in when the user did not explicitly specify
an array at index time. In fact, we had two different results depending
on whether or not users used all_fields or explicilty specified a
field. Before if you only specified {"name" : "age", "type : "number"}
as a field, you could not query for {"age" : {"$in" : [2, 3]}}. You
had to explicitly add {"name" : "age.[]", "type : "number"} to your
list of indexes so the $in would work. This fixes the scenario and now
should work as expected

Testing recommendations

Automated Tests added

GitHub issue number

Github Issue is this PR

  • Code is written and works correctly;
  • Changes are covered by tests;
  • Documentation reflects the changes;
really remove <fieldname>.[]:<type> when choosing index for $in
The function indexable_fields/1 is supposed to remove extraneous fields
created by the mango_selector_text:convert/1 function so that indexes
will not be bypassed during index selection time. This wasn't working
as expected in the case of $in when the user did not explicitly specify
an array at index time. In fact, we had two different results depending
on whether or not users used all_fields or explicilty specified a
field. Before if you only specified {"name" : "age", "type : "number"}
as a field, you could not query for {"age" : {"$in" : [2, 3]}}. You
had to explicitly add {"name" : "age.[]", "type : "number"} to your
list of indexes so the $in would work. This fixes the scenario and now
should work as expected

@tonysun83 tonysun83 requested review from garrensmith and davisp Aug 15, 2017

@garrensmith

I'm not particularly familiar with mango and text indexes. But the tests pass and code looks good.

@davisp

davisp approved these changes Aug 15, 2017

+1

@tonysun83 tonysun83 merged commit 5e00109 into master Aug 15, 2017

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details

wohali added a commit that referenced this pull request Oct 19, 2017

really remove <fieldname>.[]:<type> when choosing index for $in (#752)
The function indexable_fields/1 is supposed to remove extraneous fields
created by the mango_selector_text:convert/1 function so that indexes
will not be bypassed during index selection time. This wasn't working
as expected in the case of $in when the user did not explicitly specify
an array at index time. In fact, we had two different results depending
on whether or not users used all_fields or explicilty specified a
field. Before if you only specified {"name" : "age", "type : "number"}
as a field, you could not query for {"age" : {"$in" : [2, 3]}}. You
had to explicitly add {"name" : "age.[]", "type : "number"} to your
list of indexes so the $in would work. This fixes the scenario and now
should work as expected

@tonysun83 tonysun83 deleted the mango-in-operator branch Mar 8, 2018

willholley added a commit to willholley/couchdb that referenced this pull request May 22, 2018

really remove <fieldname>.[]:<type> when choosing index for $in (#752)
The function indexable_fields/1 is supposed to remove extraneous fields
created by the mango_selector_text:convert/1 function so that indexes
will not be bypassed during index selection time. This wasn't working
as expected in the case of $in when the user did not explicitly specify
an array at index time. In fact, we had two different results depending
on whether or not users used all_fields or explicilty specified a
field. Before if you only specified {"name" : "age", "type : "number"}
as a field, you could not query for {"age" : {"$in" : [2, 3]}}. You
had to explicitly add {"name" : "age.[]", "type : "number"} to your
list of indexes so the $in would work. This fixes the scenario and now
should work as expected
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment