[
https://issues.apache.org/jira/browse/FLINK-11447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16757126#comment-16757126
]
Timo Walther edited comment on FLINK-11447 at 1/31/19 10:59 AM:
----------------------------------------------------------------
Thanks for joining the discussion [~hequn8128].
First of all, in my opinion, we don't need to be completely in sync with SQL in
the Table API. The goal should be to have a clear and fluent API. The more
classes we introduce the more import issues occur and the more people miss
interesting features. With a {{joinLateral}} method, users get this feature
suggested in their IDE.
The {{Lateral}} keyword "allows the sub-SELECT to refer to columns of FROM
items that appear before it in the FROM list", however, it is very unlikely
that we will ever support correlated subqueries in Table API. We will only use
it for table functions.
If we were aiming for being in sync with SQL, we would need something like:
{code}
myTable.join(Lateral(Table("split(a)").as("word, length")))
myTable.join(Lateral(tableEnv.scan("OtherTable"))))
myTable.join(Lateral(tableEnv.sql("SELECT correlatedSubQuery? FROM..."))))
{code}
Because lateral itself can be used for both SQL subqueries or expressions with
a {{TABLE}} keyword.
Why should users be able to filter, groupBy, or window on a lateral table? A
lateral table should not exist on its own and this is also expressed in the SQL
standard.
was (Author: twalthr):
Thanks for joining the discussion [~hequn8128].
First of all, in my opinion, we don't need to be completely in sync with SQL in
the Table API. The goal should be to have a clear and fluent API. The more
classes we introduce the more import issues occur and the more people miss
interesting features. With a {{joinLateral}} method, users get this feature
suggested in their IDE.
The {{Lateral}} keyword "allows the sub-SELECT to refer to columns of FROM
items that appear before it in the FROM list", however, it is very unlikely
that we will ever support correlated subqueries in Table API. We will only use
it for table functions.
If we were aiming for being in sync with SQL, we would need something like:
{code}
myTable.join(Lateral(Table("split(a)").as("word, length")))
myTable.join(Lateral(tableEnv.scan("OtherTable"))))
myTable.join(Lateral(tableEnv.sql("SELECT correlatedSubQuery? FROM..."))))
{code}
Because lateral itself can be used for both SQL subqueries or expressions with
a {{TABLE}} keyword.
Why should users be able to filter, groupBy, or window on a lateral table? A
lateral table should not exist on its own.
> Deprecate "new Table(TableEnvironment, String)"
> -----------------------------------------------
>
> Key: FLINK-11447
> URL: https://issues.apache.org/jira/browse/FLINK-11447
> Project: Flink
> Issue Type: New Feature
> Components: Table API & SQL
> Reporter: Timo Walther
> Assignee: Dian Fu
> Priority: Major
>
> A more detailed description can be found in
> [FLIP-32|https://cwiki.apache.org/confluence/display/FLINK/FLIP-32%3A+Restructure+flink-table+for+future+contributions].
> Once table is an interface we can easily replace the underlying
> implementation at any time. The constructor call prevents us from converting
> it into an interface.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
