The discuss will be open for at least 72 hours to collect dicisions.--
Best！
Xuyang
At 2025-01-03 12:06:38, "Xuyang" <xyzhong...@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
