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>
> 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.
> 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