Thanks for driving this Kurt. Because we already have DDL and Descriptor as an alternative of these deprecated methods, removing them would reduce ambiguity and make the near future work more easier.
As we discussed offline, although some of the connectors may still have attributes that cannot be specified though properties, removing them force us to re-think the TableFactory/properties interface. Best, Danny Chan 在 2020年2月5日 +0800 PM3:58，Dawid Wysakowicz <dwysakow...@apache.org>，写道： > Hi Kurt, > > I fully agree with the proposal. Yes it was an omission that we did not > deprecate the TableEnvironment#fromTableSource in the previous version. > > I would vote to remove all those methods altogether. > > Best, > > Dawid > > On 05/02/2020 07:36, Kurt Young wrote: > > Hi all, > > > > I'd like to bring up a discussion about removing registration of > > TableSource and > > TableSink in TableEnvironment as well as in ConnectTableDescriptor. The > > affected > > method would be: > > > > TableEnvironment::registerTableSource > > TableEnvironment::fromTableSource > > TableEnvironment::registerTableSink > > ConnectTableDescriptor::registerTableSource > > ConnectTableDescriptor::registerTableSink > > ConnectTableDescriptor::registerTableSourceAndSink > > > > (Most of them are already deprecated, except for > > TableEnvironment::fromTableSource, > > which was intended to deprecate but missed by accident). > > > > FLIP-64 [1] already explained why we want to deprecate TableSource & > > TableSink from > > user's interface. In a short word, these interfaces should only read & > > write the physical > > representation of the table, and they are not fitting well after we already > > introduced some > > logical table fields such as computed column, watermarks. > > > > Another reason is the exposure of registerTableSource in Table Env just > > make the whole > > SQL protocol opposite. TableSource should be used as a reader of table, it > > should rely on > > other metadata information held by framework, which eventually comes from > > DDL or > > ConnectDescriptor. But if we register a TableSource to Table Env, we have > > no choice but > > have to rely on TableSource::getTableSchema. It will make the design > > obscure, sometimes > > TableSource should trust the information comes from framework, but > > sometimes it should > > also generate its own schema information. > > > > Furthermore, if the authority about schema information is not clear, it > > will make things much > > more complicated if we want to improve the table api usability such as > > introducing automatic > > schema inference in the near future. > > > > Since this is an API break change, I've also included user mailing list to > > gather more feedbacks. > > > > Best, > > Kurt > > > > [1] > > https://cwiki.apache.org/confluence/display/FLINK/FLIP-64%3A+Support+for+Temporary+Objects+in+Table+module > > >
