Thanks Junrui for driving the proposal. +1 from my side. This FLIP will help to make the configuration clearer for users.
ps: We should also delete the private field `storage` as its getter and setter are deleted and it is marked as `@Deprecated`. This is not written in the FLIP. Best, Hang Yuxin Tan <tanyuxinw...@gmail.com> 于2023年11月3日周五 11:30写道： > Thanks Junrui for driving the proposal. > > +1 for this proposal. I believe this change will enhance the usability of > Flink configuration for both users and developers, while also ensuring > consistency across various types of configurations. > > Best, > Yuxin > > > Lijie Wang <wangdachui9...@gmail.com> 于2023年11月3日周五 10:59写道： > > > Thanks Junrui for driving this. > > > > Making configurations simple and consistent has great benefits for both > > users and devs. +1 for the proposal. > > > > Best, > > Lijie > > > > weijie guo <guoweijieres...@gmail.com> 于2023年11月2日周四 16:49写道： > > > > > Thanks Junrui for driving this proposal! > > > > > > I believe this is helpful for the new Process Function API. Because we > > > don't need to move some related class/components from flink-core to a > > pure > > > API module (maybe, called flink-core-api) after this. Even though the > > FLIP > > > related to new API is in preparation atm, I still want to emphasize our > > > goal is that user application should no longer depend on these stuff. > So > > > I'm + 1 for this proposal. > > > > > > > > > Best regards, > > > > > > Weijie > > > > > > > > > Zhu Zhu <reed...@gmail.com> 于2023年11月2日周四 16:00写道： > > > > > > > Thanks Junrui for creating the FLIP and kicking off this discussion. > > > > > > > > The community has been constantly striving to unify and simplify the > > > > configuration layer of Flink. Some progress has already been made, > > > > such as FLINK-29379. However, the compatibility of public interfaces > > > > poses an obstacle to completing the task. The release of Flink 2.0 > > > > presents a great opportunity to accomplish this goal. > > > > > > > > +1 for the proposal. > > > > > > > > Thanks, > > > > Zhu > > > > > > > > Rui Fan <1996fan...@gmail.com> 于2023年11月2日周四 10:27写道： > > > > > > > > > Thanks Junrui for driving this proposal! > > > > > > > > > > ConfigOption is easy to use for flink users, easy to manage options > > > > > for flink platform maintainers, and easy to maintain for flink > > > developers > > > > > and flink community. > > > > > > > > > > So big +1 for this proposal! > > > > > > > > > > Best, > > > > > Rui > > > > > > > > > > On Thu, Nov 2, 2023 at 10:10 AM Junrui Lee <jrlee....@gmail.com> > > > wrote: > > > > > > > > > > > Hi devs, > > > > > > > > > > > > I would like to start a discussion on FLIP-381: Deprecate > > > configuration > > > > > > getters/setters that return/set complex Java objects[1]. > > > > > > > > > > > > Currently, the job configuration in FLINK is spread out across > > > > different > > > > > > components, which leads to inconsistencies and confusion. To > > address > > > > this > > > > > > issue, it is necessary to migrate non-ConfigOption complex Java > > > objects > > > > > to > > > > > > use ConfigOption and adopt a single Configuration object to host > > all > > > > the > > > > > > configuration. > > > > > > However, there is a significant blocker in implementing this > > > solution. > > > > > > These complex Java objects in StreamExecutionEnvironment, > > > > > CheckpointConfig, > > > > > > and ExecutionConfig have already been exposed through the public > > API, > > > > > > making it challenging to modify the existing implementation. > > > > > > > > > > > > Therefore, I propose to deprecate these Java objects and their > > > > > > corresponding getter/setter interfaces, ultimately removing them > in > > > > > > FLINK-2.0. > > > > > > > > > > > > Your feedback and thoughts on this proposal are highly > appreciated. > > > > > > > > > > > > Best regards, > > > > > > Junrui Lee > > > > > > > > > > > > [1] > > > > > > > > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=278464992 > > > > > > > > > > > > > > > > > > > > >
