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

Fix range query edge cases #41160

Merged
merged 5 commits into from
Apr 16, 2019
Merged

Fix range query edge cases #41160

merged 5 commits into from
Apr 16, 2019

Conversation

cbuescher
Copy link
Member

Currently we throw an error when a range querys minimum value exceeds the
maximum value due to the fact that they are neighbouring values and both
upper and lower value are excluded from the interval. Since this is a condition
that the user usually doesn't specify conciously (at least in the case of float
and double values its difficult to see which values are adjacent) we should
ignore those "wrong" intervals and create a MatchNoDocsQuery in those cases.

We should still throw errors with an actionable message if the user specifies
the query interval in a way that min value > max value. This PR adds those
checks and tests for those cases.

Closes #40937

Currently we throw an error when a range querys minimum value exceeds the
maximum value due to the fact that they are neighbouring values and both
upper and lower value are excluded from the interval. Since this is a condition
that the user usually doesn't specify conciously (at least in the case of float
and double values its difficult to see which values are adjacent) we should
ignore those "wrong" intervals and create a MatchNoDocsQuery in those cases.

We should still throw errors with an actionable message if the user specifies
the query interval in a way that min value > max value. This PR adds those
checks and tests for those cases.
@cbuescher cbuescher added >bug >enhancement :Search/Search Search-related issues that do not fall into other categories v8.0.0 v7.2.0 labels Apr 12, 2019
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-search

@cbuescher cbuescher requested a review from not-napoleon April 12, 2019 16:20
@cbuescher
Copy link
Member Author

@not-napoleon you showed some interest in this case, would you mind taking a look?

Copy link
Member

@not-napoleon not-napoleon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left comments that need addressing. Also, this is going to conflict with a PR I'm working on, but you should merge first and I'll fix the conflict in my branch. This is fixing an actual bug, and I still have test cases to write.

// wrong argument order, this is an error the user should fix
throw new IllegalArgumentException("Range query `from` value (" + from + ") is greater than `to` value (" + to + ")");
}
Double correctedFrom = (Double) from + (includeFrom ? 0 : 1);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think increasing by 1 here is wrong; that's too big a jump for doubles. We should use RangeType.DOUBLE.nextUp() here, I think. E.g., if a user specifies the exclusive range (0, 1), we would expect it to intersect the range (.3, .7), but this logic will return MatchNoDocsQuery.

In fact, I wonder if we should just have one createQuery function that's written in terms ofnextUp(), possibly accepting a comparator too, if necessary.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed, I had this in an earlier version of this PR, must have slipped, will update.

// wrong argument order, this is an error the user should fix
throw new IllegalArgumentException("Range query `from` value (" + from + ") is greater than `to` value (" + to + ")");
}
Float correctedFrom = (Float) from + (includeFrom ? 0 : 1);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See below comment for doubles ranges; floats should also use nextUp() instead of just increasing by 1.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I'll try creating only one createQuery function...

@cbuescher
Copy link
Member Author

@not-napoleon thanks for the feedback, I changed to nextUp/Down and created a single createQuery() method for the numeric types. I left IP out since its a special kind of snowflake and probably easier to handle on its own.

@not-napoleon
Copy link
Member

LGTM.

If it was me, I'd put a comment on the static createQuery explaining that IP is a special case and gets it's own createQuery function, just so someone changing it gets a warning there's a second place to look. But that's personal preference, so feel free to not if you prefer.

@cbuescher
Copy link
Member Author

I'd put a comment on the static createQuery explaining that IP is a special case

Since there are still test failures that require another re-run I might just do that ;-)

@cbuescher
Copy link
Member Author

@elasticmachine run elasticsearch-ci/packaging-sample

@cbuescher cbuescher merged commit 778a1d0 into elastic:master Apr 16, 2019
cbuescher pushed a commit that referenced this pull request Apr 16, 2019
Currently we throw an error when a range querys minimum value exceeds the
maximum value due to the fact that they are neighbouring values and both upper
and lower value are excluded from the interval.

Since this is a condition that the user usually doesn't specify conciously (at
least in the case of float and double values its difficult to see which values
are adjacent) we should ignore those "wrong" intervals and create a
MatchNoDocsQuery in those cases.

We should still throw errors with an actionable message if the user specifies
the query interval in a way that min value > max value. This PR adds those
checks and tests for those cases.

Closes #40937
gurkankaymak pushed a commit to gurkankaymak/elasticsearch that referenced this pull request May 27, 2019
Currently we throw an error when a range querys minimum value exceeds the
maximum value due to the fact that they are neighbouring values and both upper
and lower value are excluded from the interval.

Since this is a condition that the user usually doesn't specify conciously (at
least in the case of float and double values its difficult to see which values
are adjacent) we should ignore those "wrong" intervals and create a
MatchNoDocsQuery in those cases.

We should still throw errors with an actionable message if the user specifies
the query interval in a way that min value > max value. This PR adds those
checks and tests for those cases.

Closes elastic#40937
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>bug >enhancement :Search/Search Search-related issues that do not fall into other categories v7.2.0 v8.0.0-alpha1
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[CI] RangeQueryBuilderTests fails reproducibly
4 participants