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 <jinfeng1...@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 <xyzhong...@163.com> wrote: > > > +1 to delete the overrided default methods that throw exceptions. > > > > > > > > > > -- > > > > Best！ > > Xuyang > > > > > > > > > > 在 2025-01-03 12:55:38，"Xuyang" <xyzhong...@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" <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 > > >
