[
https://issues.apache.org/jira/browse/BEAM-1276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15826813#comment-15826813
]
Kenneth Knowles commented on BEAM-1276:
---------------------------------------
Agree tremendously. I would propose the following approach generally:
1. A new interface named TBD where the accumulator type is fixed and known by
the function itself. I'll choose a terrible name to be sure it is renamed:
{{MonomorphicCombineFn}} that has a parameterless {{getAccumulatorCoder()}}
method.
2. Any {{CombineFn}} that does not require the input type or coder registry
ported to implement this interface.
3. {{StateSpecs.combiningValue(MonomorphicCombineFn)}} that makes it easy to
use with state.
> StateSpecs.combiningValue interface is very awkward to use
> ----------------------------------------------------------
>
> Key: BEAM-1276
> URL: https://issues.apache.org/jira/browse/BEAM-1276
> Project: Beam
> Issue Type: Bug
> Components: sdk-java-core
> Reporter: Daniel Mills
> Assignee: Kenneth Knowles
> Priority: Minor
>
> Using StateSpecs.combiningValue with built in combiners is very verbose. For
> example, to keep a running sum of ints:
> {code}
> @StateId("count")
> private final StateSpec<Object, AccumulatorCombiningState<Integer, int[],
> Integer>> countSpec =
> StateSpecs.combiningValue(
> Sum.ofIntegers().getAccumulatorCoder(pipeline.getCoderRegistry(),
> VarIntCoder.of()), Sum.ofIntegers());
> {code}
> This involves getting a reference to the pipeline into the DoFn,
> guessing/finding the proper type parameters for Sum.ofIntegers(), and
> manually pulling the accumulator coder out.
> For combiners like Sum.ofIntegers() that have a fixed accumulator, the
> combiningValue call should be able to deduce that. Additionally, it would be
> nice to remove the type of the accumulator from the StateSpec object, since
> the user only needs the input and output types in their code.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
