[
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 the {{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 the {{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)
