Thanks dawid, +1 for this approach. One concern is the removal of registerTableSink & registerTableSource in TableEnvironment. It has two alternatives: 1.the properties approach (DDL, descriptor). 2.from/toDataStream.
#1 can only be properties, not java states, and some Connectors are difficult to convert all states to properties. #2 can contain java state. But can't use TableSource-related features, like project & filter push down, partition support, etc.. Any idea about this? Best, Jingsong Lee ------------------------------------------------------------------ From:Dawid Wysakowicz <dwysakow...@apache.org> Send Time:2019年9月4日(星期三) 22:20 To:dev <dev@flink.apache.org> Subject:[DISCUSS] FLIP-64: Support for Temporary Objects in Table module Hi all, As part of FLIP-30 a Catalog API was introduced that enables storing table meta objects permanently. At the same time the majority of current APIs create temporary objects that cannot be serialized. We should clarify the creation of meta objects (tables, views, functions) in a unified way. Another current problem in the API is that all the temporary objects are stored in a special built-in catalog, which is not very intuitive for many users, as they must be aware of that catalog to reference temporary objects. Lastly, different APIs have different ways of providing object paths: String path…, String path, String pathContinued… String name We should choose one approach and unify it across all APIs. I suggest a FLIP to address the above issues. Looking forward to your opinions. FLIP link: https://cwiki.apache.org/confluence/display/FLINK/FLIP-64%3A+Support+for+Temporary+Objects+in+Table+module
