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
> > > > >
> > > >
> > >
> >
>

Reply via email to