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)
