-
Notifications
You must be signed in to change notification settings - Fork 25k
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
SQL: IN does not behave as expected #38424
Labels
Comments
Pinging @elastic/es-search |
Thanks for the report. We'll look into it however it is unlikely the fix will be backported all the way to the 6.5.x line. |
That's fine, thanks. I have my eyes set on 6.7 and the support for combining |
matriv
added a commit
to matriv/elasticsearch
that referenced
this issue
Feb 5, 2019
Add resolution to the exact keyword field (if exists) for text fields. Add proper verification and error message if underlying keyword doesn't exist. Move check for field attribute in the comparison list to the `resolveType()` method of `IN`. Fixes: elastic#38424
matriv
added a commit
that referenced
this issue
Feb 6, 2019
) - Add resolution to the exact keyword field (if exists) for text fields. - Add proper verification and error message if underlying keyword doesn'texist. - Move check for field attribute in the comparison list to the `resolveType()` method of `IN`. Fixes: #38424
@paulcarey Thanks for reporting! The fix will be available in the releases marked by the version labels in the issue and the relevant PR. |
matriv
added a commit
that referenced
this issue
Feb 6, 2019
) - Add resolution to the exact keyword field (if exists) for text fields. - Add proper verification and error message if underlying keyword doesn'texist. - Move check for field attribute in the comparison list to the `resolveType()` method of `IN`. Fixes: #38424
matriv
added a commit
that referenced
this issue
Feb 6, 2019
) - Add resolution to the exact keyword field (if exists) for text fields. - Add proper verification and error message if underlying keyword doesn'texist. - Move check for field attribute in the comparison list to the `resolveType()` method of `IN`. Fixes: #38424
matriv
added a commit
that referenced
this issue
Feb 6, 2019
) - Add resolution to the exact keyword field (if exists) for text fields. - Add proper verification and error message if underlying keyword doesn'texist. - Move check for field attribute in the comparison list to the `resolveType()` method of `IN`. Fixes: #38424
matriv
added a commit
that referenced
this issue
Feb 6, 2019
) - Add resolution to the exact keyword field (if exists) for text fields. - Add proper verification and error message if underlying keyword doesn'texist. - Move check for field attribute in the comparison list to the `resolveType()` method of `IN`. Fixes: #38424
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
Using ES 6.5.4 I would expect queries of the form
WHERE foo = 'a' OR foo = 'b'
to return exactly the same results asWHERE foo IN ('a', 'b')
. However, this is not what I'm observing.Running my queries through
/translate
shows a material difference in how these are generated.Using
IN
:Using repeated
OR
clauses:What really seems to matter here though is that using
OR
causes ES to refer to the.keyword
instance of a field that contains the following mapping:If I modify my
IN
query toWHERE foo.keyword IN ('a', 'b')
then the results are as expected.The text was updated successfully, but these errors were encountered: