-
Notifications
You must be signed in to change notification settings - Fork 13.9k
[FLINK-12254][table] Update cast() and TypeLiteralExpression to new type system #8510
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
Conversation
|
Thanks a lot for your contribution to the Apache Flink project. I'm the @flinkbot. I help the community Review Progress
Please see the Pull Request Review Guide for a full explanation of the review process. DetailsThe Bot is tracking the review progress through labels. Labels are applied according to the order of the review items. For consensus, approval by a Flink committer of PMC member is required Bot commandsThe @flinkbot bot supports the following commands:
|
dawidwys
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally +1. Before merging I would only slightly improve the deprecation note on expressionDsl#cast
|
|
||
| /** | ||
| * Expression that wraps {@link TypeInformation} as a literal. | ||
| * Expression that wraps {@link DataType} as a literal. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: How about we add a note why do we need it? That this is primarily used for casts.
| call(CAST, expr, typeLiteral(toType)) | ||
|
|
||
| /** | ||
| * @deprecated Use [[cast(DataType)]] instead. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: Could we add a bit longer note that it might be unsafe to mix the DataType and TypeInformation stacks?
| // check for constant | ||
| return ExpressionUtils.extractValue(e, BasicTypeInfo.INT_TYPE_INFO) | ||
| .map((v) -> (Expression) valueLiteral(v * multiplier, TimeIntervalTypeInfo.INTERVAL_MONTHS)) | ||
| .orElse( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This changes the behavior of this method right? Previously e.g. (1 + 3).toMonthInterval or even (1 + f0).toMonthInterval was possible right? (Even though e.g. the window aggregation did not accept it)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that's right but this behavior was not even tested somewhere and for simplification of the design I think it is ok to limit the values to constants. What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree, just wanted to double check.
|
Thanks for the feedback @dawidwys. I updated the PR. Will merge this once Travis is green. |
|
@flinkbot approve all |
What is the purpose of the change
This PR updates
ImplicitExpressionOperations#castandTypeLiteralExpression. The Java expression API remains untouched for now.This PR builds on top of #8500.
Brief change log
cast()TypeLiteralExpressionVerifying this change
This change is already covered by existing tests.
Does this pull request potentially affect one of the following parts:
@Public(Evolving): yesDocumentation