The point of PushbackSideInputDoFnRunner is to buffer the main input until
the side input is ready (for a  sometimes complicated definition of ready).

One possibility is instead to add a new prior step in the graph that is
responsible for buffering these inputs. That way there's no need for a
special DoFnRunner at all here.


On Fri, Mar 2, 2018 at 1:01 PM Romain Manni-Bucau <rmannibu...@gmail.com>
wrote:

> Hi guys,
>
> what's the rational behind PushbackSideInputDoFnRunner?
>
> Why not using a DoFnRunner<WindowedValue<InputT>, OutputT>?
>
> It is the same thing I think, better represents what it does (most is
> delegated in general) and avoids yet another API which is not even
> implemented completely in 1 of the 2 implementation cause the interface is
> not relevant for one case (onTimer in ProcessFnRunner).
>
> Worse case we keep the pushbacksideinputdofnrunner interface but extends
> the dofn one to avoid to define other methods and we just break the process
> method name which is the only one which was not copied (not sure why).
>
> Personally I'd be to drop completely the interface but aliasing the first
> one with a default method to bridge the process methods sounds good as well
> and allows to reduce the forked code between both branches.
>
> wdyt?
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>

Reply via email to