[Rollup] Log deprecation if config and request intervals are mixed #33284
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
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`.
polyfractal
added
>bug
review
:StorageEngine/Rollup
|
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. |
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. |
|
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
| */ | ||
| static boolean validateMixedInterval(long requestInterval, DateHistogramInterval configInterval) { | ||
| if (isCalendarInterval(configInterval)) { | ||
| long configIntervalMillis = CALENDAR_ORDERING.getOrDefault(configInterval.toString(), Long.MAX_VALUE); |
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) { |
There was a problem hiding this comment.
should we also turn this breaking change in a deprecation warning ?
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); |
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();
?
There was a problem hiding this comment.
Didn't realize you could do this. ++
|
Tidied up, and added a few more tests for the multiples warning |
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.
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.