[
https://issues.apache.org/jira/browse/FLINK-5026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15701738#comment-15701738
]
ASF GitHub Bot commented on FLINK-5026:
---------------------------------------
Github user kl0u commented on a diff in the pull request:
https://github.com/apache/flink/pull/2788#discussion_r89760994
--- Diff:
flink-streaming-java/src/main/java/org/apache/flink/streaming/api/functions/co/CoProcessFunction.java
---
@@ -50,7 +46,7 @@
* @param <OUT> Output type.
--- End diff --
I would make it like:
/**
* A function that processes elements of two streams and produces a single
output one.
*
* <p>The function will be called for every element in the input streams
and can produce
* zero or more output elements. Contrary to the {@link CoFlatMapFunction},
this function can also
* query the time (both event and processing) and set timers, through the
provided {@link Context}.
* When reacting to the firing of set timers the function can emit yet more
elements.
*
* <p>An example use-case for connected streams would be the application of
a set of rules that change
* over time ({@code stream A}) to the elements contained in another stream
(stream {@code B}). The rules
* contained in {@code stream A} can be stored in the state and wait for
new elements to arrive on
* {@code stream B}. Upon reception of a new element on {@code stream B},
the function can now apply the
* previously stored rules to the element and directly emit a result,
and/or register a timer that
* will trigger an action in the future.
Also we could have a code snippet for the example.
> Rename TimelyFlatMap to Process
> -------------------------------
>
> Key: FLINK-5026
> URL: https://issues.apache.org/jira/browse/FLINK-5026
> Project: Flink
> Issue Type: Improvement
> Components: Streaming
> Reporter: Aljoscha Krettek
> Assignee: Aljoscha Krettek
> Fix For: 1.2.0
>
>
> The method on {{KeyedDataStream}} would be called {{process()}} and the
> function itself would be called {{ProcessFunction}}.
> The reason for this is that {{TimelyFlatMapFunction}} is a bit of a mouthful
> and with the additions to the timer API and state the {{ProcessFunction}}
> could become the basic, low-level, user-facing API for cases where users
> nowadays implement their own operator.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
