[
https://issues.apache.org/jira/browse/FLINK-3869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15495761#comment-15495761
]
Aljoscha Krettek commented on FLINK-3869:
-----------------------------------------
I have another proposal for solving this: I started to dislike how the
reduce/fold with window function is called {{apply()}}. Yes, You can see the
apply with incremental aggregation as either an apply that has an additional
incremental aggregation function or as an incremental aggregation (reduce/fold)
that has an apply added to it. Right now, I think these two methods should be:
{code}
reduce(ReduceFunction, WindowFunction)
fold(Initial, FoldFunction, WindowFunction)
{code}
this would make them more discoverable, i.e. you do a reduce and then you see
that you can also give a {{WindowFunction}} to get all the meta data for the
window.
If we changed to that new naming scheme we could fix the fold restriction and
deprecate the old methods, thereby not breaking any existing code.
[~StephanEwen] what do you think?
> WindowedStream.apply with FoldFunction is too restrictive
> ---------------------------------------------------------
>
> Key: FLINK-3869
> URL: https://issues.apache.org/jira/browse/FLINK-3869
> Project: Flink
> Issue Type: Sub-task
> Components: Streaming
> Reporter: Aljoscha Krettek
> Assignee: Aljoscha Krettek
>
> Right now we have this signature:
> {code}
> public <R> SingleOutputStreamOperator<R> apply(R initialValue,
> FoldFunction<T, R> foldFunction, WindowFunction<R, R, K, W> function) {
> {code}
> but we should have this signature to allow users to return a type other than
> the fold accumulator type from their window function:
> {code}
> public <ACC, R> SingleOutputStreamOperator<R> apply(ACC initialValue,
> FoldFunction<T, ACC> foldFunction, WindowFunction<ACC, R, K, W> function) {
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
