THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
Methods of TableEnvironment
Current call | Replacement | Comment |
registerTable | createTemporaryView | For the non temporary part we need to make `QueryOperation` string serializable. |
registerTableSink | (Deprecate) | |
registerTableSource | (Deprecate) | |
registerDataStream | createTemporaryView | |
registerScalarFunction/ registerAggergateFunction/ registerTableFunction | createTemporaryFunction | We can unify the 3 methods into one once we rework type inference for UDFs |
New suggested methods:
Current call | Comment |
dropTemporaryTable | |
dropTemporaryView | |
dropTemporaryFunction |
Methods of ConnectTableDescriptor
Current call | Replacement | SQL equivalent | Comment |
registerTableSource | (Deprecate) | - | |
registerTableSink | (Deprecate) | - | |
registerTableSourceAndSink | createTemporaryTable | CREATE TEMPORARY TABLE | We should not support CREATE TEMPORARY TABLE AS SELECT = CREATE TEMPORARY VIEW |
Persistent API - not part of the FLIP
Implementation, nor design of those API calls is not part of the FLIP. It is just to show that the permanent API is a separate concept that requires further work.
Call to add | SQL equivalent | Comment | |||
createView(Table) | CREATE VIEW | We need to make `QueryOperation`s string serializable. | |||
createTable(TableDescriptor) | CREATE TABLE | We need to rework TableDescriptor. We can temporary use ConnectTableDescriptor#connect | |||
createFunction | CREATE FUNCTION | We need serializable function representation |
Referencing objects
I suggest to change the way we address objects in the API to unify it across SQL/Table API & different objects. We should always specify path as a single string and parse it into a catalog/database/object-name subparts.
...
All objects are identified with 3 part identifiers (catalog name, database name, object name).
We suggest to enable overriding catalog objects with temporary objects. This means it would be possible to register temporary table with identifier `cat1`.`db1`.`tmpTab`. Even if `tmpTab` exists in the `cat1` catalog in `db1` database. Moreover we suggest to allow registering temporary objects in a path that does not exist. This means a user can register e.g. a table in a catalog or database that does not exist.
...
We suggest to always treat the temporary function in the 3 part category. The reason is that overwriting a
Therefore the resolution logic would be following:
- built-in functions (1-part name)
- temporary functions (3-part path, expanded if provided with less than 3 parts)
- catalog functions (3-part path, expanded if provided with less than 3 parts)
For the write path, all temporary objects would always be expanded to 3 part identifiers, with the current catalog & current database if needed.
We suggest to introduce an in-memory maps in CatalogManager:
...