You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@flink.apache.org by "Bowen Li (JIRA)" <ji...@apache.org> on 2018/10/31 19:20:00 UTC

[jira] [Comment Edited] (FLINK-10686) Introduce a flink-table-common module

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

Bowen Li edited comment on FLINK-10686 at 10/31/18 7:19 PM:
------------------------------------------------------------

How about parallelize the subtasks of FLINK-10688 and FLINK-10689?

Given that FLINK-10687 is done and {{flink-table-common}} is created, rather than waiting for FLINK-10688 and being blocked, I think a better way to make progress is:
 * finish this subtask first by porting {{org.apache.flink.table.catalog}} and {{org.apache.flink.table.functions}} to {{flink-table-common}}
 * let {{flink-connectors}} temporarily depends on both {{flink-table}} and {{flink-table-common}}
 * As part of FLINK-10688, we can remove {{flink-connectors}} 's dependency on {{flink-table}} then.

The reasons being that the community is starting to work on Flink-Hive integration and external catalogs. Since we've already decided to move UDFs/catalogs APIs to Java, I don't think writing new scala code then porting to Java is cumbersome and time-consuming is a good option. I'd rather port existing code to Java first and then start to write all new code/feature. With the way I proposed, we can parallelize the work and FLINK-10689 won't get blocked by FLINK-10688.

What do you think? [~twalthr]


was (Author: phoenixjiangnan):
How about parallelize the subtasks of FLINK-10688 and FLINK-10689?

Given that FLINK-10687 is done and \{{flink-table-common}} is created, rather than waiting for FLINK-10688 and being blocked, I think a better way to make progress is:
 * finish this subtask first by porting \{{org.apache.flink.table.catalog}} and \{{org.apache.flink.table.functions}} to \{{flink-table-common}}
 * let \{{flink-connectors}} temporarily depends on both \{{flink-table}} and \{{flink-table-common}}
 * As part of FLINK-10688, we can remove \{{flink-connectors}} 's dependency on \{{flink-table}} then.

The reasons being that the community is starting to work on Flink-Hive integration and external catalogs. Since we've already decided to move UDFs/catalogs APIs to Java, I don't think writing new scala code then porting to Java is cumbersome and time-consuming is a good option. I'd rather port existing code to Java first and then start to write all new code/feature. With the way I proposed, we can parallelize the work and FLINK-10689 won't get blocked by FLINK-10688.

What do you think? [~twalthr]

> Introduce a flink-table-common module
> -------------------------------------
>
>                 Key: FLINK-10686
>                 URL: https://issues.apache.org/jira/browse/FLINK-10686
>             Project: Flink
>          Issue Type: Improvement
>          Components: Table API &amp; SQL
>    Affects Versions: 1.7.0
>            Reporter: Timo Walther
>            Assignee: Timo Walther
>            Priority: Major
>             Fix For: 1.7.0
>
>
> Because more and more table factories for connectors and formats are added and external catalog support is also on the horizon, {{flink-table}} becomes a dependency for many Flink modules. Since {{flink-table}} is implemented in Scala it requires other modules to be suffixes with Scala prefixes. However, as we have learned in the past, Scala code is hard to maintain which is why our long-term goal is to avoid Scala/Scala dependencies.
> Therefore we propose a new module {{flink-table-common}} that contains interfaces between {{flink-table}} and other modules. This module is implemented in Java and should contain minimal (or better no) external dependencies.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)