[Rollup] Log deprecation if config and request intervals are mixed#33284
Merged
jimczi merged 6 commits intoelastic:6.4from Sep 3, 2018
Merged
[Rollup] Log deprecation if config and request intervals are mixed#33284jimczi merged 6 commits intoelastic:6.4from
jimczi merged 6 commits intoelastic:6.4from
Conversation
Backport of elastic#32052, with some changes. In 6.5, we forbid mixed intervals (one fixed, one calendar). But for a 6.4.x bugfix release this would be a pretty extreme break. So we continue to allow mixed intervals in 6.4, but log a deprecation warning. 6.4 also doesn't enforce that the request is a multiple of the config. We also log a deprecation if that is not the case, but don't prevent the query. Finally, mixed intervals are only used if a better job cap can't be found. To support the case where we have to compare fixed and calendar, there is a table of rough conversions (e.g. 1 day == 86400000ms). This lets us crudely ensure the user doesn't try to query `2d` on an index that is set for `1w`.
Collaborator
|
Pinging @elastic/es-search-aggs |
polyfractal
commented
Aug 30, 2018
| intervals, the <<rollup-search>> API can aggregate on any time interval hourly or greater. Intervals that are less than an hour will throw | ||
| an exception, since the data simply doesn't exist for finer granularities. | ||
| Rollups are stored at a certain granularity, as defined by the `date_histogram` group in the configuration. This means you | ||
| can only search/aggregate the rollup data with an interval that is greater-than or equal to the configured rollup interval. |
Contributor
Author
There was a problem hiding this comment.
This isn't technically true, but I'm inclined to leave as-is to encourage proper config in 6.4 :)
polyfractal
commented
Aug 30, 2018
| A non-multiple wouldn't work, since the rolled up data wouldn't cleanly "overlap" with the buckets generated | ||
| by the aggregation, leading to incorrect results. | ||
|
|
||
| For that reason, an error is thrown if a whole multiple of the configured interval isn't found. |
Contributor
Author
|
Note: I also spotted a bug in the comparator, similar to the parsing bug that's being fixed. But I'd like to fix that in a followup PR because it applies to all branches. |
jimczi
reviewed
Aug 30, 2018
Contributor
jimczi
left a comment
There was a problem hiding this comment.
It looks good @polyfractal , I left some comments
| */ | ||
| static boolean validateMixedInterval(long requestInterval, DateHistogramInterval configInterval) { | ||
| if (isCalendarInterval(configInterval)) { | ||
| long configIntervalMillis = CALENDAR_ORDERING.getOrDefault(configInterval.toString(), Long.MAX_VALUE); |
Contributor
There was a problem hiding this comment.
We need to log the deprecation warning if the statement below is true ?
| // TODO should be divisor of interval | ||
| if (interval <= source.interval()) { | ||
| // query interval must be gte the configured interval, and a whole multiple | ||
| if (interval <= source.interval() && source.interval() % interval == 0) { |
Contributor
There was a problem hiding this comment.
should we also turn this breaking change in a deprecation warning ?
Contributor
Author
There was a problem hiding this comment.
argh, yes. adding thanks
| // The request must be gte the config. The CALENDAR_ORDERING map values are integers representing | ||
| // relative orders between the calendar units | ||
| long requestOrder = CALENDAR_ORDERING.getOrDefault(requestInterval.toString(), Long.MAX_VALUE); | ||
| long configOrder = CALENDAR_ORDERING.getOrDefault(configInterval.toString(), Long.MAX_VALUE); |
Contributor
There was a problem hiding this comment.
You can maybe replace the static map with:
DateTimeUnit configUnit = DateHistogramAggregationBuilder.DATE_FIELD_UNITS.get(configInterval.toString());
long configOrder = configUnit.field(DateTimeZone.UTC).getDurationField().getUnitMillis();
?
Contributor
Author
There was a problem hiding this comment.
Didn't realize you could do this. ++
added 3 commits
August 31, 2018 11:41
Contributor
Author
|
Tidied up, and added a few more tests for the multiples warning |
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
Backport of #32052, with some changes.
In 6.5, we forbid mixed intervals (one fixed, one calendar). But for a 6.4.x bugfix release this would be a pretty extreme break. So we continue to allow mixed intervals in 6.4, but log a deprecation warning.
6.4 also doesn't enforce that the request is a multiple of the config. So we log a deprecation if that is not the case, but don't prevent the query.
Finally, mixed intervals are only used if a better job cap can't be found.
To support the case where we have to compare fixed and calendar, there is a table of rough conversions (e.g. 1 day == 86400000ms). This lets us crudely ensure the user doesn't try to query
2don an index that is set for1w.@jimczi Mind giving a quick review on this? The major change from the other PR is the addition of
validateMixedInterval(), changes to theCALENDAR_ORDERINGtable, and that we don't enforce multiples.