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 <[email protected]> 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> >
