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

Timo Walther commented on FLINK-2099:
-------------------------------------

I had a private discussion with [~rmetzger], [~StephanEwen], [~aljoscha] and 
[~fhueske].

Where we came to consensus (correct me if I'm wrong or missed something):
- Build SQL API on top of Table API
- Use Apache Calcite for SQL parsing and logical optimization, without 
providing schema information
- Let Table API's optimizer do basic optimizations so far and maybe use 
Calcites relational algebra optimizer in the future

Meanwhile I made myself familiar with Apache Calcite and could not found a way 
how we can do logical optimization without schema information. The question is 
now: Do we really want to "connect" the SQL parse tree directly with the Table 
API? Wouldn't it make sense to integrate the SQL into the Table API and use 
schema information so that Calcite can optimize SQL completely (resolve 
problems with correlated subqueries etc.)?

>From a users perspective it could look like this:
{code}
TableEnvironment tableEnv = new TableEnvironment();
DataSet<WC> input = env.fromElements(
                                new WC("Hello", 1),
                                new WC("Ciao", 1),
                                new WC("Hello", 1));
Table table = tableEnv.fromDataSet(input, "MYTABLE"); // registers the table 
schema in TableEnvironment
table.select("...") // simple expressions with Table API
Table resultTable = tableEnv.sql("SELECT name FROM MYTABLE") // complex 
expressions with SQL
{code}



> Add a SQL API
> -------------
>
>                 Key: FLINK-2099
>                 URL: https://issues.apache.org/jira/browse/FLINK-2099
>             Project: Flink
>          Issue Type: New Feature
>          Components: Table API
>            Reporter: Timo Walther
>            Assignee: Timo Walther
>
> From the mailing list:
> Fabian: Flink's Table API is pretty close to what SQL provides. IMO, the best
> approach would be to leverage that and build a SQL parser (maybe together
> with a logical optimizer) on top of the Table API. Parser (and optimizer)
> could be built using Apache Calcite which is providing exactly this.
> Since the Table API is still a fairly new component and not very feature
> rich, it might make sense to extend and strengthen it before putting
> something major on top.
> Ted: It would also be relatively simple (I think) to retarget drill to Flink 
> if
> Flink doesn't provide enough typing meta-data to do traditional SQL.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to