Add support for numeric range keys #56452
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This adds support for parsing numbers as range keys. They get converted into a string, but we allow numbers. While I was there I replaced the parser for `Range` with a `ConstructingObjectParser` which will automatically add support for "did you mean" style corrections on errors. Closes elastic#56402
|
Pinging @elastic/es-analytics-geo (:Analytics/Aggregations) |
elasticmachine
added
the
Team:Analytics
polyfractal
approved these changes
May 11, 2020
| @@ -128,50 +132,6 @@ public String toString() { | |||
| return "[" + from + " to " + to + ")"; | |||
| } | |||
|
|
|||
| public static Range fromXContent(XContentParser parser) throws IOException { | |||
polyfractal
reviewed
May 11, 2020
| @@ -63,6 +67,14 @@ | |||
| protected final double to; | |||
| protected final String toAsStr; | |||
|
|
|||
| public Range(String key, Double from, String fromAsStr, Double to, String toAsStr) { | |||
There was a problem hiding this comment.
I wonder if we should add a guard here to throw an exception if from/fromAsStr and to/toAsStr are both non-null/non-empty/not infinity? Looks like we previously were just assuming the user gave us the right combination... i'm assuming we use these preferentially later (e.g. toAsStr if non-null, to otherwise or something like that)
Or if it turns out to be a big mess, at least a javadoc explaining the priority? Or make it package-private if possible? Not sure where else it's used though
There was a problem hiding this comment.
It is used in a few places, yeah. I believe the best I can do is describe the priority. I'll do that.
nik9000
added a commit
to nik9000/elasticsearch
that referenced
this pull request
May 11, 2020
This adds support for parsing numbers as range keys. They get converted into a string, but we allow numbers. While I was there I replaced the parser for `Range` with a `ConstructingObjectParser` which will automatically add support for "did you mean" style corrections on errors. Closes elastic#56402
nik9000
added a commit
that referenced
this pull request
May 11, 2020
This adds support for parsing numbers as range keys. They get converted into a string, but we allow numbers. While I was there I replaced the parser for `Range` with a `ConstructingObjectParser` which will automatically add support for "did you mean" style corrections on errors. Closes #56402
29 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This adds support for parsing numbers as range keys. They get converted
into a string, but we allow numbers.
While I was there I replaced the parser for
Rangewith aConstructingObjectParserwhich will automatically add support for "didyou mean" style corrections on errors.
Closes #56402