Hi, all, we have jobs which create state according to type of the key and a dynamic configuration:
eg: key_type_1's aggregation function is average, while key_type_2's is sum we need to create state dynamically because the aggregation function may change in runtime and different aggregation function may need different state to persistent state. It is really hard to declare state eagerly. In the flip, I think the main concern to propose the eager declaration of state is to make sure when restoring we can have all states registered. how about just persisting state descriptor in state handle and automatically register states in restoring? On 5 July 2017 at 03:53, Chesnay Schepler <ches...@apache.org> wrote: > Could you add an example to the FLIP for how a user can register a state > with the methods in the RichFunction interface? > Currently it only contains an example for the annotation option. > > These methods look like they are called by the user, but that doesn't > really make sense to me as after all the user has to > implement them. > > To me a more intuitive signature would be > > |void registerKeyedState(StateDescriptorRegistry registry);| > > that is called by the system when a UDF is provided by a user who then > registers all the state descriptors he has. > > > On 04.07.2017 20:00, Tzu-Li (Gordon) Tai wrote: > >> Hi Flink devs! >> >> I would like to propose the following FLIP - Eager State Declaration for >> Flink managed state: https://cwiki.apache.org/confl >> uence/display/FLINK/FLIP-22%3A+Eager+State+Declaration. >> The proposal is a result of some offline discussions with Aljoscha >> Krettek, Stephan Ewen, and Stefan Richter. >> >> With how the current managed state declaration interfaces work, users may >> declare state lazily while jobs are running. >> This behavior is a direct blocker for several state management features >> we wish to make a reality in the future. >> I also see it as an opportunity to make the interfaces for keyed / >> operator managed state declarations more unified at the API level, as well >> as improved user experience for general use cases. >> >> The most important part of the required changes is the deprecation of >> existing APIs and introducing new state declaration interfaces. >> Since this would be a rework of the state interfaces, it would be great >> to hear thoughts on this and make sure that the proposal is what we want in >> the long run! >> >> Happy to hear feedback on this :) >> >> Cheers, >> Gordon >> > > >
