[GitHub] flink issue #3107: [FLINK-5441] [table] Directly allow SQL queries on a Tabl...

2017-03-14 Thread twalthr
Github user twalthr commented on the issue: https://github.com/apache/flink/pull/3107 Thanks @wuchong. Will merge this. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled

[GitHub] flink issue #3107: [FLINK-5441] [table] Directly allow SQL queries on a Tabl...

2017-03-13 Thread wuchong
Github user wuchong commented on the issue: https://github.com/apache/flink/pull/3107 updated the documentation. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and

[GitHub] flink issue #3107: [FLINK-5441] [table] Directly allow SQL queries on a Tabl...

2017-03-13 Thread twalthr
Github user twalthr commented on the issue: https://github.com/apache/flink/pull/3107 Thanks for the quick update @wuchong. The code looks good to merge. Can you add some documentation to the SQL section? --- If your project is set up for it, you can reply to this email and have

[GitHub] flink issue #3107: [FLINK-5441] [table] Directly allow SQL queries on a Tabl...

2017-03-13 Thread wuchong
Github user wuchong commented on the issue: https://github.com/apache/flink/pull/3107 @twalthr I have updated this PR regarding to the idea you proposed that `env.sql(s"SELECT * FROM $table JOIN $otherTable")` --- If your project is set up for it, you can reply to this email and

[GitHub] flink issue #3107: [FLINK-5441] [table] Directly allow SQL queries on a Tabl...

2017-03-13 Thread wuchong
Github user wuchong commented on the issue: https://github.com/apache/flink/pull/3107 @twalthr Yes, I will update it in these days. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this

[GitHub] flink issue #3107: [FLINK-5441] [table] Directly allow SQL queries on a Tabl...

2017-03-13 Thread twalthr
Github user twalthr commented on the issue: https://github.com/apache/flink/pull/3107 @wuchong any plans to update this PR? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature

[GitHub] flink issue #3107: [FLINK-5441] [table] Directly allow SQL queries on a Tabl...

2017-03-02 Thread fhueske
Github user fhueske commented on the issue: https://github.com/apache/flink/pull/3107 Yes, you are right. Forgot that we lazily translate the plans. :-/ Let's keep the tables then. --- If your project is set up for it, you can reply to this email and have your reply appear on

[GitHub] flink issue #3107: [FLINK-5441] [table] Directly allow SQL queries on a Tabl...

2017-03-02 Thread twalthr
Github user twalthr commented on the issue: https://github.com/apache/flink/pull/3107 I think the point is that we don't know if the table will ever be used again. If we unregister them after optimization, we can not have multiple `toDataStream()` calls for one table. --- If your

[GitHub] flink issue #3107: [FLINK-5441] [table] Directly allow SQL queries on a Tabl...

2017-03-02 Thread fhueske
Github user fhueske commented on the issue: https://github.com/apache/flink/pull/3107 But what's the point of keeping tables that will never be used again? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project

[GitHub] flink issue #3107: [FLINK-5441] [table] Directly allow SQL queries on a Tabl...

2017-03-02 Thread twalthr
Github user twalthr commented on the issue: https://github.com/apache/flink/pull/3107 Do we have to take care of unregistering the tables? Right now `fromDataSet/fromDataStream` do also not unregister their unique names. --- If your project is set up for it, you can reply to this

[GitHub] flink issue #3107: [FLINK-5441] [table] Directly allow SQL queries on a Tabl...

2017-02-22 Thread fhueske
Github user fhueske commented on the issue: https://github.com/apache/flink/pull/3107 Hmm, I think registering tables in `toString()` (which IMO should be free of side effects) is not very clean, but I have to admit that the API looks good. So, I would be OK doing this like that.

[GitHub] flink issue #3107: [FLINK-5441] [table] Directly allow SQL queries on a Tabl...

2017-02-22 Thread wuchong
Github user wuchong commented on the issue: https://github.com/apache/flink/pull/3107 Thank you @twalthr , I like the idea. So Java users can also use `env.sql("SELECT * FROM " + table1 + " JOIN " + table2)` as a shortcut. What do you think @fhueske ? --- If your project is set up

[GitHub] flink issue #3107: [FLINK-5441] [table] Directly allow SQL queries on a Tabl...

2017-02-22 Thread twalthr
Github user twalthr commented on the issue: https://github.com/apache/flink/pull/3107 @wuchong if `toString` is called for the first time. It calls `tEnv.registerTableInternal(this)` which uses an atomic counter and generates a unique identifier such as `UnnamedTable$232`. This

[GitHub] flink issue #3107: [FLINK-5441] [table] Directly allow SQL queries on a Tabl...

2017-02-22 Thread fhueske
Github user fhueske commented on the issue: https://github.com/apache/flink/pull/3107 An external catalog would not help in this case. It's actually quite the opposite. The issue is to run a SQL query on an ad-hoc table without the need to explicitly add it to a catalog. --- If

[GitHub] flink issue #3107: [FLINK-5441] [table] Directly allow SQL queries on a Tabl...

2017-02-22 Thread fpompermaier
Github user fpompermaier commented on the issue: https://github.com/apache/flink/pull/3107 It's for this reason that I think that Flink needs a "source catalog" somewhere.. On 22 February 2017 at 09:35, twalthr wrote: > We don't have to

[GitHub] flink issue #3107: [FLINK-5441] [table] Directly allow SQL queries on a Tabl...

2017-02-22 Thread wuchong
Github user wuchong commented on the issue: https://github.com/apache/flink/pull/3107 @twalthr do you mean register table in his `toString` method ? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does

[GitHub] flink issue #3107: [FLINK-5441] [table] Directly allow SQL queries on a Tabl...

2017-02-22 Thread twalthr
Github user twalthr commented on the issue: https://github.com/apache/flink/pull/3107 We don't have to intercept inline string arguments. We just have to make sure that `Table.toString()` returns an unique identifier that the method previously registered in it's table environment.

[GitHub] flink issue #3107: [FLINK-5441] [table] Directly allow SQL queries on a Tabl...

2017-02-21 Thread fhueske
Github user fhueske commented on the issue: https://github.com/apache/flink/pull/3107 Agreed, for Scala the inlined variant looks really good. Like @wuchong, I'm curious how we can intercept the inlined string arguments. Do you know how to do that @twalthr? --- If your project

[GitHub] flink issue #3107: [FLINK-5441] [table] Directly allow SQL queries on a Tabl...

2017-02-20 Thread wuchong
Github user wuchong commented on the issue: https://github.com/apache/flink/pull/3107 Hi @twalthr , the `env.sql(s"SELECT * FROM $table JOIN $otherTable")` is a nice way. But how to handle the table's table name and register it to env ? --- If your project is set up for it, you can

[GitHub] flink issue #3107: [FLINK-5441] [table] Directly allow SQL queries on a Tabl...

2017-02-20 Thread twalthr
Github user twalthr commented on the issue: https://github.com/apache/flink/pull/3107 What do you think about my solution of `env.sql(s"SELECT * FROM $table JOIN $otherTable")`? It would be much more readable. --- If your project is set up for it, you can reply to this email and

[GitHub] flink issue #3107: [FLINK-5441] [table] Directly allow SQL queries on a Tabl...

2017-02-17 Thread KurtYoung
Github user KurtYoung commented on the issue: https://github.com/apache/flink/pull/3107 Hi @fhueske, both solutions are fine with me. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this

[GitHub] flink issue #3107: [FLINK-5441] [table] Directly allow SQL queries on a Tabl...

2017-02-17 Thread fhueske
Github user fhueske commented on the issue: https://github.com/apache/flink/pull/3107 Hi, I like @twalthr's suggestion to use `env.sql("SELECT * FROM _ JOIN _", table, otherTable)`. I'd also be fine with slf4j syntax as @wuchong proposed. What do you think @KurtYoung?

[GitHub] flink issue #3107: [FLINK-5441] [table] Directly allow SQL queries on a Tabl...

2017-02-01 Thread wuchong
Github user wuchong commented on the issue: https://github.com/apache/flink/pull/3107 What about using slf4j syntax `env.sql("SELECT * FROM {} JOIN {}", table1, table2)` ? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as

[GitHub] flink issue #3107: [FLINK-5441] [table] Directly allow SQL queries on a Tabl...

2017-01-30 Thread twalthr
Github user twalthr commented on the issue: https://github.com/apache/flink/pull/3107 @KurtYoung I agree that this syntax can be misused like `table.sql("SELECT * FROM otherTable")`. But right now it is very inconvenient to always register a table first, especially if you want to

[GitHub] flink issue #3107: [FLINK-5441] [table] Directly allow SQL queries on a Tabl...

2017-01-14 Thread KurtYoung
Github user KurtYoung commented on the issue: https://github.com/apache/flink/pull/3107 I still think this is weird. Currently all API from `Table` is somehow act on the table object, just like a normal OOP program. After introducing `sql` method to `Table`, it can do something

[GitHub] flink issue #3107: [FLINK-5441] [table] Directly allow SQL queries on a Tabl...

2017-01-13 Thread wuchong
Github user wuchong commented on the issue: https://github.com/apache/flink/pull/3107 Hi @KurtYoung , thank your for reviewing. I'm not sure about that. Do you mean omitting the "FROM" syntax ? But it will be hard to validate SQL syntax. Because the query can follow a WHERE clause