-
Notifications
You must be signed in to change notification settings - Fork 13.8k
[FLINK-12283][table] Relax UDF constraints by using the ClosureCleaner #10519
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 Automated ChecksLast check on commit 4ca7743 (Tue Dec 10 16:17:20 UTC 2019) Warnings:
Mention the bot in a comment to re-run the automated checks. 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:
|
CI report:
Bot commandsThe @flinkbot bot supports the following commands:
|
|
@zjffdu does this PR also works for you? Or will the ClosureCleaner complain about the non-serializability? |
|
@twalthr Could you do a rebase against master so that I can test is in Zeppelin ? |
|
@zjffdu rebased |
|
It works in Zeppelin, thanks @twalthr +1 |
| if (definition instanceof ScalarFunctionDefinition) { | ||
| final ScalarFunctionDefinition sf = (ScalarFunctionDefinition) definition; | ||
| UserDefinedFunctionHelper.prepareFunction(resolutionContext.configuration(), sf.getScalarFunction()); | ||
| return new ScalarFunctionDefinition( |
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.
Why do we need to return new definitions from this methdod? Having the if blocks here can break things in the future if we add more function definition types.
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 method is just a temporary solution until FLIP-65 is implemented. In the future, we don't need to store the type next to the function but the function provides a strategy for determining the type.
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.
Ok, good to merge, then!
|
I had one inline comment. Other than that this PR seems good! |
|
Thank you @aljoscha. Merging... |
This relaxes the UDF constraints as much as possible by using the ClosureCleaner. For Java users, this is very convenient. For Scala users, it improves the current status but we still need to fix FLINK-15162. It ensures that the validation and cleaning happens at exactly 2 locations. Either during registration in the function catalog or during resolution of inline, unregistered functions. This closes apache#10519.
|
@flinkbot run travis |
This relaxes the UDF constraints as much as possible by using the ClosureCleaner. For Java users, this is very convenient. For Scala users, it improves the current status but we still need to fix FLINK-15162. It ensures that the validation and cleaning happens at exactly 2 locations. Either during registration in the function catalog or during resolution of inline, unregistered functions. This closes #10519.
What is the purpose of the change
This PR relaxes the UDF constraints as much as possible by using the ClosureCleaner. For Java users, this is very convenient. For Scala users, it improves the current status but we still need to fix FLINK-15162.
Brief change log
This PR ensures that the validation and cleaning happens at exactly 2 locations. Either during registration in the function catalog or during resolution of inline, unregistered functions.
Since the ClosureCleaner needs configuration parameters, this PR also adds configuration through the stack. But this makes sense for the future in any case because configuration should be the first known instance when creating a table environment.
Verifying this change
Integration tests added for Blink and legacy planner.
Does this pull request potentially affect one of the following parts:
@Public(Evolving): yesDocumentation