add EARLIEST_BY/LATEST_BY to make EARLIEST/LATEST function signatures less ambiguous #12145
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
imply-cheddar
suggested changes
Jan 12, 2022
docs/querying/sql.md
Outdated
| |`EARLIEST(expr, maxBytesPerString)`|Like `EARLIEST(expr)`, but for strings. The `maxBytesPerString` parameter determines how much aggregation space to allocate per string. Strings longer than this limit will be truncated. This parameter should be set as low as possible, since high values will lead to wasted memory.|`null` if `druid.generic.useDefaultValueForNull=false`, otherwise `''`| | ||
| |`EARLIEST(expr, maxBytesPerString, timeColumn)`|Like `EARLIEST(expr, timeColumn)`, but for strings. The `maxBytesPerString` parameter determines how much aggregation space to allocate per string. Strings longer than this limit will be truncated. This parameter should be set as low as possible, since high values will lead to wasted memory.|`null` if `druid.generic.useDefaultValueForNull=false`, otherwise `''`| | ||
| |`EARLIEST_BY(expr, timeColumn)`|Returns the earliest value of `expr`, which must be numeric. Earliest value is defined as the value first encountered with the minimum overall value of time column of all values being aggregated.|`null` if `druid.generic.useDefaultValueForNull=false`, otherwise `0`| | ||
| |`EARLIEST_BY(expr, maxBytesPerString, timeColumn)`|Like `EARLIEST_BY(expr, timeColumn)`, but for strings. The `maxBytesPerString` parameter determines how much aggregation space to allocate per string. Strings longer than this limit will be truncated. This parameter should be set as low as possible, since high values will lead to wasted memory.|`null` if `druid.generic.useDefaultValueForNull=false`, otherwise `''`| |
There was a problem hiding this comment.
With EARLIEST_BY I'd suggest we swap the location of timeColumn and maxBytesPerString. Given that timeColumn is non-optional on the _BY items, we want the optional parameter to be at the end of the signature.
gianm
reviewed
Jan 12, 2022
| OperandTypes.sequence( | ||
| "'" + aggregatorType.name() + "(expr, timeColumn)'\n", | ||
| OperandTypes.ANY, | ||
| OperandTypes.NUMERIC |
There was a problem hiding this comment.
IMO we should allow either NUMERIC or TIMESTAMP here.
There was a problem hiding this comment.
Hmm, thinking about it more, IMO we should only allow TIMESTAMP. That's consistent with what our other time functions do.
There was a problem hiding this comment.
changed, and this found a bug when i had to switch to column that could actually be converted to TIMESTAMP (a long), we weren't correctly checking if the time column selector had null values, so I've fixed up the native aggregators to handle this case.
imply-cheddar
approved these changes
Jan 12, 2022
gianm
reviewed
Jan 12, 2022
.idea/inspectionProfiles/Druid.xml
Outdated
| @@ -70,7 +70,6 @@ | |||
| </option> | |||
| <option name="IGNORE_FIELDS_USED_IN_MULTIPLE_METHODS" value="true" /> | |||
| </inspection_tool> | |||
| <inspection_tool class="FieldMayBeFinal" enabled="true" level="WARNING" enabled_by_default="true" /> | |||
There was a problem hiding this comment.
Was this change (& the others in this file) intentional?
gianm
approved these changes
Jan 12, 2022
sachinsagare
pushed a commit
to pinterest/druid
that referenced
this pull request
Oct 28, 2022
… less ambiguous (apache#12145) * add EARLIEST_BY/LATEST_BY to make EARLIEST/LATEST function signatures unambiguous * switcheroo * EARLIEST_BY/LATEST_BY use timestamp instead of numeric types, update docs * revert unintended change * fix docs * fix docs better (cherry picked from commit f2ce769) Signed-off-by: ssagare <[email protected]>
sachinsagare
pushed a commit
to sachinsagare/druid
that referenced
this pull request
Nov 3, 2022
… less ambiguous (apache#12145) * add EARLIEST_BY/LATEST_BY to make EARLIEST/LATEST function signatures unambiguous * switcheroo * EARLIEST_BY/LATEST_BY use timestamp instead of numeric types, update docs * revert unintended change * fix docs * fix docs better Signed-off-by: ssagare <[email protected]>
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.
Description
Follow-up to #11949, this PR splits explicit time column functions into standalone
EARLIEST_BYandLATEST_BYSQL functions to avoid the method signatures being ambiguous and dependent on the column types of the inputs.Prior to this PR, something like
latest(x, 10)could either translate to "latest" value of x with max bytes of 10 if a string, but if x was a number it would treat the10as a timestamp, so instead of a validation exception like would happen prior to #11949, it would allow it but then explode with strange cast exceptions due to unintended behavior on the users part.Splitting this out into separate functions makes it much less likely for the user to issue the incorrect query.
This PR has: