ASF GitHub Bot commented on FLINK-5185:

GitHub user beyond1920 opened a pull request:


    [FLINK-5185] [Table API & SQL] Decouple BatchTableSourceScan with 

    The pr aims to decouple BatchTableSourceScan with TableSourceTable for 
further optimization, e.g, projection pushdown/filter pushdown/query pushdown.  
The principle is  let BatchTableSourceScan directly holding TableSource instead 
of holding TableSourceTable.
    The main changes including:
    1. change constructors of BatchScan/BatchTableSourceScan/DataSetScan
    2. Extract the logic logical of build row types based on fields types and 
fields name into FlinkTypeFactory class.

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/alibaba/flink jira-5185

Alternatively you can review and apply these changes as the patch at:


To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #2921
commit d0718ff512a931cf0bb024df516a36215f486df5
Author: beyond1920 <beyond1...@126.com>
Date:   2016-11-29T04:26:02Z

    modify constructor of BatchScan, BatchTableSourceScan, DataSetScan
    Test Plan: junit
    Reviewers: kete.yangkt
    Differential Revision: http://phabricator.taobao.net/D6601

commit 068b2ec7df9207bf246305da3dd744fcd339844a
Author: beyond1920 <beyond1...@126.com>
Date:   2016-11-30T01:21:42Z

    modify code style and extract common method

commit fe0ac06e7a76663100a76ec91c8873de8def548b
Author: beyond1920 <beyond1...@126.com>
Date:   2016-11-30T03:21:36Z

    let rule decide which tableSource to create a BatchTableScan

commit 1e4bebaaf2d0e23dc561d42feceecb4537336b57
Author: beyond1920 <beyond1...@126.com>
Date:   2016-12-01T03:45:34Z

    Decouple BatchTableSourceScan with TableSourceTable

commit 7d558b723a3241a63b1ecdcfb92f15b7676f71bc
Author: beyond1920 <beyond1...@126.com>
Date:   2016-12-01T07:36:42Z

    make long length shorter to pass the flink code style check


> 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

Reply via email to