I believe DoFnSignature#isStateful is remnant of a bad API name choice and was renamed to usesState. I would remove DoFnSignature#isStateful as it does not seem to be used anywhere.
Does DoFnSignatures#usesValueState return true if the DoFn says it needs @RequiresTimeSortedInput because of how a DoFn is being "wrapped" with a stateful DoFn that provides the time sorting functionality? That doesn't seem right since I would have always expected that DoFnSignature(s) should be about the DoFn passed in and not about the implementation details that a runner might be using in how it provides @RequiresTimeSortedInput. (similarly for DoFnSignatures#usesBagState, DoFnSignatures#usesWatermarkHold, DoFnSignatures#usesTimers, DoFnSignatures#usesState) On Mon, May 25, 2020 at 2:31 AM Jan Lukavský <[email protected]> wrote: > Hi, > > I have come across issue with multiple way of getting a meaningful flags > for DoFns. We have > > a) DoFnSignature#{usesState,usesTimers,isStateful,...}, and > > b) DoFnSignatures#{usesState,usesTimers,isStateful,...} > > These two might not (and actually are not) aligned with each other. That > can be solved quite easily (removing any logic from DoFnSignatures and > put it to DoFnSignature), but what I'm not sure is why > DoFnSignature#isStateful is deprecated in favor of > DoFnSignature#usesState. In my understanding, it should hold that > `isStateful() iff usesState() || usesTimers()`, which means these two > should not be used interchangeably. I'd suggest to undeprecate the > `DoFnSignature#isStateful` and align the various (static and non-static) > versions of these calls. > > Thoughts? > > Jan > >
