I would NOT have to depend on the next committed callback to do some transfer of data or cleanup. Since I have to wait till the next committed callback, I need to hold this data separately and handle it when I get the next committed callback.
If the committed window is provided in setup this can be contained to setup. I can't think of any downside of providing it. We added ACTIVATION_WINDOW_ID which is also a convenience, so the same argument can be made for this. Thanks, Chandni On Thu, Mar 10, 2016 at 2:30 PM, Pramod Immaneni <[email protected]> wrote: > Can you provide an example of where this would make your operator purge > logic more straightforward? > > Thanks > > On Thu, Mar 10, 2016 at 1:30 PM, Chandni Singh <[email protected]> > wrote: > > > Hi, > > > > I was working on managed state and felt that some cleanup can be easier > if > > the last committed window id is accessible to all operator during setup - > > maybe a DAG level Attribute. > > > > I don't think this requires a lot of code change. Also just an additional > > attribute so just an attribute addition to API. > > > > I would like to work on this change if they aren't any objections. > > > > Thanks, > > Chandni > > >
