Some areas of the Beam model in the SDK alluded to the use of a compressed representation of an element along with the set of windows it is assigned to. However, the model itself views elements in different windows as fully independent, so the SDK should not place any obligation on the part of the runner or user to use a particular representation.
This change <https://github.com/apache/incubator-beam/commit/08104410177063b1095bd91b24b40f9961c92cf2> removed those places in the SDK where an element is treated in multiple windows at once. This was done by exploding the compressed representation so [(W1, W2), V] became [W1, V] and [W2, V] On Mon, Aug 15, 2016 at 7:25 AM, Shen Li <[email protected]> wrote: > Hi, > > I am a little confused about the usage of internal IdentityWindowFn. My > current understanding is that it should be used when a transform wants to > change window configurations (e.g., triggering, lateness, etc.) without > modifying the window assignments. Is that correct? If so, how come > IdentifyWindowFn.assignWindows() returns a collection of a single > BoundedWindow? What if the upstream WindowFn assigns an element to multiple > windows (e.g., SlidingWindows)? > > Thanks, > > Shen >
