You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flink.apache.org by Xuyang <xy...@163.com> on 2025/01/03 04:06:38 UTC
[DISSCUSS] Removing default error methods from the new public api stack in the table api when it implements both the new and deprecated public api stacks and the old stack is removed
Hi, all.
Feng Jing, Ron Liu and I are are currently working on removing deprecated public APIs from the table module and have encountered an issue.
Take CatalogFactory as an example, the CatalogFactory class implements both the new api Factory and the deprecated api TableFactory. Within
CatalogFactory, all methods of the new api Factory have default implementations that currently return errors, providing compatibility with the old
api TableFactory. As we move forward with the removal of the deprecated api TableFactory, we are uncertain about whether to remove the default
methods from the new api Factory.
There are two options:
1. Leave it unchanged for now: The advantage of this approach is that we adhere to the principle of not modifying public APIs at all. However, I believe that having missed the release-2.0, we may not have another opportunity to remove it in the near future. Additionally, this option is not very user-friendly for custom connectors, as they would only discover the absence of certain methods at runtime.
2. Directly remove the default implementations where throw exceptions directly: The benefit of this approach is that it informs users at compile time that they must implement certain methods. The downside is that we are "slightly" modifying the public API methods. Connectors that are very old and only compatible with the old API stack without integrating the new API stack would encounter compile-time errors (although in any case, they would ultimately face runtime errors, wouldn’t they?).
We would appreciate any insights or suggestions regarding this decision. Thank you!
Please note that similar situations exist with ModuleFactory and others; we won't discuss each one individually going forward.
--
Best！
Xuyang
Re:Re: Re:[DISSCUSS] Removing default error methods from the new public api stack in the table api when it implements both the new and deprecated public api stacks and the old stack is removed
Posted by Xuyang <xy...@163.com>.
Hi, all.
Given that there have been no objections or additional comments, we will proceed to remove
the default implementation classes of the affected classes. Thank you to everyone who was
involved.
--
Best！
Xuyang
在 2025-01-03 13:41:16，"Ron Liu" <ro...@gmail.com> 写道：
>Hi, Xuyang
>
>Thanks for initialized this proposal. +1 for remove the default
>implementation because 2.0 is breaking change, we don't need to keep api
>compatibility.
>
>Best,
>Ron
>
>Feng Jin <ji...@gmail.com> 于2025年1月3日周五 13:36写道：
>
>> +1 Directly remove the default implementation, as this allows issues to be
>> detected at compile time rather than at runtime. Even if we keep these
>> methods, it doesn’t seem to make much sense.
>>
>>
>> Best,
>> Feng Jin
>>
>>
>> On Fri, Jan 3, 2025 at 12:57 PM Xuyang <xy...@163.com> wrote:
>>
>> > +1 to delete the overrided default methods that throw exceptions.
>> >
>> >
>> >
>> >
>> > --
>> >
>> > Best！
>> > Xuyang
>> >
>> >
>> >
>> >
>> > 在 2025-01-03 12:55:38，"Xuyang" <xy...@163.com> 写道：
>> >
>> > The discuss will be open for at least 72 hours to collect dicisions.
>> >
>> > --
>> >
>> > Best！
>> > Xuyang
>> >
>> >
>> >
>> >
>> >
>> > At 2025-01-03 12:06:38, "Xuyang" <xy...@163.com> wrote:
>> > >Hi, all.
>> > >
>> > >Feng Jing, Ron Liu and I are are currently working on removing
>> deprecated
>> > public APIs from the table module and have encountered an issue.
>> > >
>> > >Take CatalogFactory as an example, the CatalogFactory class implements
>> > both the new api Factory and the deprecated api TableFactory. Within
>> > >
>> > >CatalogFactory, all methods of the new api Factory have default
>> > implementations that currently return errors, providing compatibility
>> with
>> > the old
>> > >
>> > >api TableFactory. As we move forward with the removal of the deprecated
>> > api TableFactory, we are uncertain about whether to remove the default
>> > >
>> > >methods from the new api Factory.
>> > >
>> > >There are two options:
>> > >
>> > >1. Leave it unchanged for now: The advantage of this approach is that we
>> > adhere to the principle of not modifying public APIs at all. However, I
>> > believe that having missed the release-2.0, we may not have another
>> > opportunity to remove it in the near future. Additionally, this option is
>> > not very user-friendly for custom connectors, as they would only discover
>> > the absence of certain methods at runtime.
>> > >
>> > >2. Directly remove the default implementations where throw exceptions
>> > directly: The benefit of this approach is that it informs users at
>> compile
>> > time that they must implement certain methods. The downside is that we
>> are
>> > "slightly" modifying the public API methods. Connectors that are very old
>> > and only compatible with the old API stack without integrating the new
>> API
>> > stack would encounter compile-time errors (although in any case, they
>> would
>> > ultimately face runtime errors, wouldn’t they?).
>> > >
>> > >We would appreciate any insights or suggestions regarding this decision.
>> > Thank you!
>> > >
>> > >
>> > >
>> > >
>> > >Please note that similar situations exist with ModuleFactory and others;
>> > we won't discuss each one individually going forward.
>> > >
>> > >
>> > >
>> > >
>> > >--
>> > >
>> > > Best！
>> > > Xuyang
>> >
>>
Re: Re:[DISSCUSS] Removing default error methods from the new public api stack in the table api when it implements both the new and deprecated public api stacks and the old stack is removed
Posted by Ron Liu <ro...@gmail.com>.
Hi, Xuyang
Thanks for initialized this proposal. +1 for remove the default
implementation because 2.0 is breaking change, we don't need to keep api
compatibility.
Best,
Ron
Feng Jin <ji...@gmail.com> 于2025年1月3日周五 13:36写道：
> +1 Directly remove the default implementation, as this allows issues to be
> detected at compile time rather than at runtime. Even if we keep these
> methods, it doesn’t seem to make much sense.
>
>
> Best,
> Feng Jin
>
>
> On Fri, Jan 3, 2025 at 12:57 PM Xuyang <xy...@163.com> wrote:
>
> > +1 to delete the overrided default methods that throw exceptions.
> >
> >
> >
> >
> > --
> >
> > Best！
> > Xuyang
> >
> >
> >
> >
> > 在 2025-01-03 12:55:38，"Xuyang" <xy...@163.com> 写道：
> >
> > The discuss will be open for at least 72 hours to collect dicisions.
> >
> > --
> >
> > Best！
> > Xuyang
> >
> >
> >
> >
> >
> > At 2025-01-03 12:06:38, "Xuyang" <xy...@163.com> wrote:
> > >Hi, all.
> > >
> > >Feng Jing, Ron Liu and I are are currently working on removing
> deprecated
> > public APIs from the table module and have encountered an issue.
> > >
> > >Take CatalogFactory as an example, the CatalogFactory class implements
> > both the new api Factory and the deprecated api TableFactory. Within
> > >
> > >CatalogFactory, all methods of the new api Factory have default
> > implementations that currently return errors, providing compatibility
> with
> > the old
> > >
> > >api TableFactory. As we move forward with the removal of the deprecated
> > api TableFactory, we are uncertain about whether to remove the default
> > >
> > >methods from the new api Factory.
> > >
> > >There are two options:
> > >
> > >1. Leave it unchanged for now: The advantage of this approach is that we
> > adhere to the principle of not modifying public APIs at all. However, I
> > believe that having missed the release-2.0, we may not have another
> > opportunity to remove it in the near future. Additionally, this option is
> > not very user-friendly for custom connectors, as they would only discover
> > the absence of certain methods at runtime.
> > >
> > >2. Directly remove the default implementations where throw exceptions
> > directly: The benefit of this approach is that it informs users at
> compile
> > time that they must implement certain methods. The downside is that we
> are
> > "slightly" modifying the public API methods. Connectors that are very old
> > and only compatible with the old API stack without integrating the new
> API
> > stack would encounter compile-time errors (although in any case, they
> would
> > ultimately face runtime errors, wouldn’t they?).
> > >
> > >We would appreciate any insights or suggestions regarding this decision.
> > Thank you!
> > >
> > >
> > >
> > >
> > >Please note that similar situations exist with ModuleFactory and others;
> > we won't discuss each one individually going forward.
> > >
> > >
> > >
> > >
> > >--
> > >
> > > Best！
> > > Xuyang
> >
>
Re: Re:[DISSCUSS] Removing default error methods from the new public api stack in the table api when it implements both the new and deprecated public api stacks and the old stack is removed
Posted by Feng Jin <ji...@gmail.com>.
+1 Directly remove the default implementation, as this allows issues to be
detected at compile time rather than at runtime. Even if we keep these
methods, it doesn’t seem to make much sense.
Best,
Feng Jin
On Fri, Jan 3, 2025 at 12:57 PM Xuyang <xy...@163.com> wrote:
> +1 to delete the overrided default methods that throw exceptions.
>
>
>
>
> --
>
> Best！
> Xuyang
>
>
>
>
> 在 2025-01-03 12:55:38，"Xuyang" <xy...@163.com> 写道：
>
> The discuss will be open for at least 72 hours to collect dicisions.
>
> --
>
> Best！
> Xuyang
>
>
>
>
>
> At 2025-01-03 12:06:38, "Xuyang" <xy...@163.com> wrote:
> >Hi, all.
> >
> >Feng Jing, Ron Liu and I are are currently working on removing deprecated
> public APIs from the table module and have encountered an issue.
> >
> >Take CatalogFactory as an example, the CatalogFactory class implements
> both the new api Factory and the deprecated api TableFactory. Within
> >
> >CatalogFactory, all methods of the new api Factory have default
> implementations that currently return errors, providing compatibility with
> the old
> >
> >api TableFactory. As we move forward with the removal of the deprecated
> api TableFactory, we are uncertain about whether to remove the default
> >
> >methods from the new api Factory.
> >
> >There are two options:
> >
> >1. Leave it unchanged for now: The advantage of this approach is that we
> adhere to the principle of not modifying public APIs at all. However, I
> believe that having missed the release-2.0, we may not have another
> opportunity to remove it in the near future. Additionally, this option is
> not very user-friendly for custom connectors, as they would only discover
> the absence of certain methods at runtime.
> >
> >2. Directly remove the default implementations where throw exceptions
> directly: The benefit of this approach is that it informs users at compile
> time that they must implement certain methods. The downside is that we are
> "slightly" modifying the public API methods. Connectors that are very old
> and only compatible with the old API stack without integrating the new API
> stack would encounter compile-time errors (although in any case, they would
> ultimately face runtime errors, wouldn’t they?).
> >
> >We would appreciate any insights or suggestions regarding this decision.
> Thank you!
> >
> >
> >
> >
> >Please note that similar situations exist with ModuleFactory and others;
> we won't discuss each one individually going forward.
> >
> >
> >
> >
> >--
> >
> > Best！
> > Xuyang
>
Re:Re:[DISSCUSS] Removing default error methods from the new public api stack in the table api when it implements both the new and deprecated public api stacks and the old stack is removed
Posted by Xuyang <xy...@163.com>.
+1 to delete the overrided default methods that throw exceptions.
--
Best！
Xuyang
在 2025-01-03 12:55:38，"Xuyang" <xy...@163.com> 写道：
The discuss will be open for at least 72 hours to collect dicisions.
--
Best！
Xuyang
At 2025-01-03 12:06:38, "Xuyang" <xy...@163.com> wrote:
>Hi, all.
>
>Feng Jing, Ron Liu and I are are currently working on removing deprecated public APIs from the table module and have encountered an issue.
>
>Take CatalogFactory as an example, the CatalogFactory class implements both the new api Factory and the deprecated api TableFactory. Within
>
>CatalogFactory, all methods of the new api Factory have default implementations that currently return errors, providing compatibility with the old
>
>api TableFactory. As we move forward with the removal of the deprecated api TableFactory, we are uncertain about whether to remove the default
>
>methods from the new api Factory.
>
>There are two options:
>
>1. Leave it unchanged for now: The advantage of this approach is that we adhere to the principle of not modifying public APIs at all. However, I believe that having missed the release-2.0, we may not have another opportunity to remove it in the near future. Additionally, this option is not very user-friendly for custom connectors, as they would only discover the absence of certain methods at runtime.
>
>2. Directly remove the default implementations where throw exceptions directly: The benefit of this approach is that it informs users at compile time that they must implement certain methods. The downside is that we are "slightly" modifying the public API methods. Connectors that are very old and only compatible with the old API stack without integrating the new API stack would encounter compile-time errors (although in any case, they would ultimately face runtime errors, wouldn’t they?).
>
>We would appreciate any insights or suggestions regarding this decision. Thank you!
>
>
>
>
>Please note that similar situations exist with ModuleFactory and others; we won't discuss each one individually going forward.
>
>
>
>
>--
>
> Best！
> Xuyang
Re:[DISSCUSS] Removing default error methods from the new public api stack in the table api when it implements both the new and deprecated public api stacks and the old stack is removed
Posted by Xuyang <xy...@163.com>.
The discuss will be open for at least 72 hours to collect dicisions.--
Best！
Xuyang
At 2025-01-03 12:06:38, "Xuyang" <xy...@163.com> wrote:
>Hi, all.
>
>Feng Jing, Ron Liu and I are are currently working on removing deprecated public APIs from the table module and have encountered an issue.
>
>Take CatalogFactory as an example, the CatalogFactory class implements both the new api Factory and the deprecated api TableFactory. Within
>
>CatalogFactory, all methods of the new api Factory have default implementations that currently return errors, providing compatibility with the old
>
>api TableFactory. As we move forward with the removal of the deprecated api TableFactory, we are uncertain about whether to remove the default
>
>methods from the new api Factory.
>
>There are two options:
>
>1. Leave it unchanged for now: The advantage of this approach is that we adhere to the principle of not modifying public APIs at all. However, I believe that having missed the release-2.0, we may not have another opportunity to remove it in the near future. Additionally, this option is not very user-friendly for custom connectors, as they would only discover the absence of certain methods at runtime.
>
>2. Directly remove the default implementations where throw exceptions directly: The benefit of this approach is that it informs users at compile time that they must implement certain methods. The downside is that we are "slightly" modifying the public API methods. Connectors that are very old and only compatible with the old API stack without integrating the new API stack would encounter compile-time errors (although in any case, they would ultimately face runtime errors, wouldn’t they?).
>
>We would appreciate any insights or suggestions regarding this decision. Thank you!
>
>
>
>
>Please note that similar situations exist with ModuleFactory and others; we won't discuss each one individually going forward.
>
>
>
>
>--
>
> Best！
> Xuyang