Makes sense. At least for accumulating mode, maintaining pane ordering cross stages will be very useful but it is indeed difficult to do so.
Now I can see why trigger at sinks might be a better approach. -Rui On Thu, Jun 27, 2019 at 9:35 AM Reuven Lax <[email protected]> wrote: > > > On Thu, Jun 27, 2019 at 3:32 AM Robert Bradshaw <[email protected]> > wrote: > >> On Thu, Jun 27, 2019 at 1:52 AM Rui Wang <[email protected]> wrote: >> >> >> >> >> >> AFAIK all streaming runners today practically do provide these panes >> in order; >> > >> > Does it refer to "the stage immediately after GBK itself processes >> fired panes in order" in streaming runners? Could you share more >> information? >> > >> > >> >> >> >> this means that likely many users implicitly rely on this "non >> guarantee," probably without even knowing they are relying on it. >> > >> > If streaming runners have already provided or processed panes in order, >> and likely many users rely on it already, why not make order of panes a >> part of model explicitly? >> >> Most runners produce panes in order, but they don't necessarily >> preserve the order downstream (at least beyond what's fused into the >> same stage, which is where it gets difficult). >> > > Actually they generally do preserve them at least to the very next fused > stage. That's why I assume many users rely on this non guarantee. >
