We know it's poor compute if all aggregates for each record completely from scratch performance. that's why we using retract method to implement BOUNDED OVER WINDOW. I think that's the best choice.
We also have add the comment in AggregateFunction for retract method.
This(retract) function must be implemented for
datastream bounded over aggregate.
So, I think we did the right thing when we do the aggregate design and implementation of the bounded over.
But I think using the retract method is an optimized implementation of bounded over window, but we can not force the user to implement the retract method. especially the business scenario is an append only table that never generates retract information, so the user may define a aggregate function that does not have a retract method. we can not force the user must implement the retract method because of the way of realization for bounded over window. And I think we may not need a lot of refactoring the original code, but on the basis of the original code to increase the non-retract method support.
Fabian Hueske I think your worry is necessary, but I do not really like the implementation of the OVER window will force the user to implement the AggregateFunction # retract method.