Re: Combine.Global

2017-04-12 Thread Paul Gerver
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. >

Re: Combine.Global

2017-04-10 Thread Thomas Groh
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

Re: Combine.Global

2017-04-07 Thread Aviem Zur
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

Re: Combine.Global

2017-04-07 Thread Aviem Zur
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

Combine.Global

2017-04-07 Thread Paul Gerver
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