[
https://issues.apache.org/jira/browse/FLINK-5185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kurt Young updated FLINK-5185:
------------------------------
Description:
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.
was:
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.
> 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)
