[jira] [Comment Edited] (FLINK-5185) Decouple BatchTableSourceScan with TableSourceTable

["Fabian Hueske (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/FLINK-5185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15709903#comment-15709903 ] 

Fabian Hueske edited comment on FLINK-5185 at 11/30/16 9:56 PM:
----------------------------------------------------------------

I assume, you are proposing this in order to create a {{BatchTableSourceScan}} with pushed down predicate or projection, right?
In this case, you would need to create a new {{TableSourceTable}} to hold the modified {{TableSource}} which projects and/or filters in the {{RelOptRule}} that translates {{LogicalScan}} and {{LogicalCalc}} to {{BatchTableSourceScan}}.
I see that this is actually a problem which needs to be fixed.

How about we just add optional parameters for projection columns and filter conditions to the {{BatchTableSouceScan}} and generate the modified {{TableSource}} inside of the {{BatchTableSouceScan.translateToPlan()}} method? Then we would not need to create a new {{TableSource}} in a {{RelOptRule}} at all but would do this when the plan is generated.


was (Author: fhueske):
I assume, you are proposing this in order to create a {{BatchTableSourceScan}} with pushed down predicate or projection, right?
In this case, you would need to create a new {{TableSourceTable}} to hold the modified {{TableSource}} which projects and/or filters in the {{RelOptRule}} that translates {{LogicalScan}} and {{LogicalCalc}} to {{BatchTableSourceScan}}.

How about we just add optional parameters for projection columns and filter conditions to the {{BatchTableSouceScan}} and generate the modified {{TableSource}} inside of the {{BatchTableSouceScan.translateToPlan()}} method? Then we would not need to create a new {{TableSource}} in a {{RelOptRule}} at all but would do this when the plan is generated.

> 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)