Skip to content

Conversation

@twalthr
Copy link
Contributor

@twalthr twalthr commented Dec 10, 2019

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:

  • Dependencies (does it add or upgrade a dependency): no
  • The public API, i.e., is any changed class annotated with @Public(Evolving): yes
  • The serializers: no
  • The runtime per-record code paths (performance sensitive): no
  • Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Yarn/Mesos, ZooKeeper: no
  • The S3 file system connector: no

Documentation

  • Does this pull request introduce a new feature? no
  • If yes, how is the feature documented? JavaDocs

@twalthr twalthr changed the title Flink 12283 [FLINK-12283][table] Relax UDF constraints by using the ClosureCleaner Dec 10, 2019
@flinkbot
Copy link
Collaborator

Thanks a lot for your contribution to the Apache Flink project. I'm the @flinkbot. I help the community
to review your pull request. We will use this comment to track the progress of the review.

Automated Checks

Last check on commit 4ca7743 (Tue Dec 10 16:17:20 UTC 2019)

Warnings:

  • No documentation files were touched! Remember to keep the Flink docs up to date!

Mention the bot in a comment to re-run the automated checks.

Review Progress

  • ❓ 1. The [description] looks good.
  • ❓ 2. There is [consensus] that the contribution should go into to Flink.
  • ❓ 3. Needs [attention] from.
  • ❓ 4. The change fits into the overall [architecture].
  • ❓ 5. Overall code [quality] is good.

Please see the Pull Request Review Guide for a full explanation of the review process.

Details
The 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 commands
The @flinkbot bot supports the following commands:

  • @flinkbot approve description to approve one or more aspects (aspects: description, consensus, architecture and quality)
  • @flinkbot approve all to approve all aspects
  • @flinkbot approve-until architecture to approve everything until architecture
  • @flinkbot attention @username1 [@username2 ..] to require somebody's attention
  • @flinkbot disapprove architecture to remove an approval you gave earlier

@flinkbot
Copy link
Collaborator

flinkbot commented Dec 10, 2019

CI report:

Bot commands The @flinkbot bot supports the following commands:
  • @flinkbot run travis re-run the last Travis build
  • @flinkbot run azure re-run the last Azure build

@twalthr
Copy link
Contributor Author

twalthr commented Dec 11, 2019

@zjffdu does this PR also works for you? Or will the ClosureCleaner complain about the non-serializability?

@zjffdu
Copy link
Contributor

zjffdu commented Dec 11, 2019

@twalthr Could you do a rebase against master so that I can test is in Zeppelin ?

@twalthr
Copy link
Contributor Author

twalthr commented Dec 11, 2019

@zjffdu rebased

@zjffdu
Copy link
Contributor

zjffdu commented Dec 11, 2019

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(
Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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!

@aljoscha
Copy link
Contributor

I had one inline comment. Other than that this PR seems good!

@twalthr
Copy link
Contributor Author

twalthr commented Dec 13, 2019

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.
@twalthr
Copy link
Contributor Author

twalthr commented Dec 17, 2019

@flinkbot run travis

@asfgit asfgit closed this in 91629d6 Dec 18, 2019
asfgit pushed a commit that referenced this pull request Dec 18, 2019
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants