Kurt Young created FLINK-5185:
---------------------------------
Summary: Decouple BatchTableSourceScan with TableSourceTable
Key: FLINK-5185
URL:
https://issues.apache.org/jira/browse/FLINK-5185 Project: Flink
Issue Type: Improvement
Components: Table API & SQL
Affects Versions: 1.2.0
Reporter: Kurt Young
Assignee: zhangjing
Priority: Minor
As the components' relationship show in this design doc:
https://docs.google.com/document/d/1PBnEbOcFHlEF1qGGAUgJvINdEXzzFTIRElgvs4-Tdeo/We found it's been annoying for BatchTableSourceScan directly holding TableSourceTable, and refer to TableSource further. It's ok if the relationship is immutable, but when we want to change the TableSource when applying optimizations, it will cause some conflicts and misunderstanding.
Since there is only one way to change TableSource, which is creating a new TableSourceTable to hold the new TableSource, and create a new BatchTableSourceScan pointing to that TableSourceTable which just created. The annoying part is the RelOptTable comes from the super class TableScan still holds the connection to the original TableSourceTable and TableSource. It will cause some misunderstanding, which one should the Scan rely to, and what's difference between these tables.
Besides, TableSourceTable is not very useful in BatchTableSourceScan, the only thing Scan cares is the RowType it returns, since this is and should be decided by TableSource. So we can let BatchTableSourceScan directly holding TableSource instead of holding TableSourceTable.If some original information are needed, find table through RelOptTable.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Locked
