Ah, I found my mistake. You overrode the getAccumulator and
getDefaultOutputCoders which my implementation did not. This approach is
straight forward now.
Thanks!
On 2017-04-07 23:46 (-0500), Aviem Zur wrote:
> I wasn't able to reproduce the issue you're experiencing.
>
This looks like it might be because the output coder cannot be determined.
It looks like the registry understands that it must build a KvCoder, but
cannot infer the coder for OutputT. More specifically, within the stack
trace, the following line occurs:
"Unable to provide a default Coder for
I wasn't able to reproduce the issue you're experiencing.
I've created a gist with an example that works and is similar to what you
have described.
Please help us make tweaks to the gist reproduce your problem:
https://gist.github.com/aviemzur/ba213d98b4484492099b3cf709ddded0
On Fri, Apr 7, 2017
Have you set the coder for your input PCollection? The one on which you
perform the Combine?
On Fri, Apr 7, 2017 at 4:24 PM Paul Gerver wrote:
> Hello All,
>
> I'm trying to test out a Combine.Globally transform which takes in a small
> custom class (CustomA) and outputs a
Hello All,
I'm trying to test out a Combine.Globally transform which takes in a small
custom class (CustomA) and outputs a secondary custom class (CustomB). I
have set the coder for the resulting PCollection, but Beam is
arguing that a coder for a KV type is missing (see output at bottom).
Since