-
Notifications
You must be signed in to change notification settings - Fork 13.9k
[FLINK-37443] Add returns() method to DataStream V2 API for specifying output types with lambda expressions #26284
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
base: master
Are you sure you want to change the base?
Changes from all commits
31c909b
e192f97
99727be
b2f1f57
f9a35c4
8f03b7c
97d605c
88949a1
082df16
eab4d02
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -19,6 +19,7 @@ | |
| package org.apache.flink.datastream.api.stream; | ||
|
|
||
| import org.apache.flink.annotation.Experimental; | ||
| import org.apache.flink.api.common.typeinfo.TypeInformation; | ||
| import org.apache.flink.api.connector.dsv2.Sink; | ||
| import org.apache.flink.api.java.functions.KeySelector; | ||
| import org.apache.flink.datastream.api.function.OneInputStreamProcessFunction; | ||
|
|
@@ -41,6 +42,20 @@ public interface NonKeyedPartitionStream<T> extends DataStream { | |
| <OUT> ProcessConfigurableAndNonKeyedPartitionStream<OUT> process( | ||
| OneInputStreamProcessFunction<T, OUT> processFunction); | ||
|
|
||
| /** | ||
| * Adds a type information hint about the return type of this operator. This method can be used | ||
| * in cases where Flink cannot determine automatically what the produced type of a function is. | ||
| * That can be the case if the function uses generic type variables in the return type that | ||
| * cannot be inferred from the input type. | ||
| * | ||
| * <p>In most cases, the methods {@link #returns(Class)} and {@link #returns(TypeHint)} are | ||
| * preferable. | ||
| * | ||
| * @param typeInfo type information as a return type hint | ||
| * @return This operator with a given return type hint. | ||
| */ | ||
| NonKeyedPartitionStream<T> returns(TypeInformation<T> typeInfo); | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. okay I will add it,
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. added
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can it be just part of datastream interface? Then it will extend all other streams by default.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Thank you for the reminder. You can add the |
||
|
|
||
| /** | ||
| * Apply a two output operation to this {@link NonKeyedPartitionStream}. | ||
| * | ||
|
|
||
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.
The API modules should not depend on non-API modules, because this would require users to depend on the flink-core module when developing DataStream V2 programs, but flink-core should only be used at application runnning.
You might consider moving
TypeInformationto the API module, such as core-api. However, I understand that this is challenging due to its dependencies on numerous other classes.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 can copy it, but will it be okay to have these duplicate code in codebase? Or is there any other better way to do that?
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.
The dependency of
flink-coremodule through usingTypeInformationis only used in the interfaces located inflink-datastream-api, as the implementations are defined inflink-datastreammodule which are already usingflink-coremodule.I think it does not make much sense to copy a large number of files and maintain it just for a small feature and that too only for defining interfaces. I am open to other ideas.
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.
Sorry for the delayed reply. I think we can introduce a class, such as
TypeHint, at the API level that allows users to define a class with generics. Subsequently, thisTypeHintcan be converted intoTypeInformationat the implementation level.During this process, you can leverage
TypeDescriptorto describe common types within theflink-datastream-api. Additionally, it would be advantageous to incorporate thetupletype intoTypeDescriptor.