+1 to what ufuk said. :D
On May 27, 2015 6:13 PM, "Kostas Tzoumas" wrote:
> very excited to see this starting!
>
> On Wed, May 27, 2015 at 6:06 PM, Ufuk Celebi wrote:
>
> >
> > On 27 May 2015, at 17:05, Timo Walther wrote:
> >
> > > It's rather passion for the future of the project than passion
very excited to see this starting!
On Wed, May 27, 2015 at 6:06 PM, Ufuk Celebi wrote:
>
> On 27 May 2015, at 17:05, Timo Walther wrote:
>
> > It's rather passion for the future of the project than passion for SQL
> ;-)
> >
> > I always try to think like someone from the economy. And IMO the gu
On 27 May 2015, at 17:05, Timo Walther wrote:
> It's rather passion for the future of the project than passion for SQL ;-)
>
> I always try to think like someone from the economy. And IMO the guys from
> economy are still thinking in SQL. If you want to persuade someone coming
> from the SQL
It's rather passion for the future of the project than passion for SQL ;-)
I always try to think like someone from the economy. And IMO the guys
from economy are still thinking in SQL. If you want to persuade someone
coming from the SQL world, you should offer a SQL interface to run
legacy cod
+1 for committer passion!
Please don't get me wrong, I think SQL on Flink would be a great feature.
I just wanted to make the point that the Table API needs to mirror all SQL
features, if SQL is implemented on top of the Table API.
2015-05-27 16:34 GMT+02:00 Kostas Tzoumas :
> I think Fabian's
I think Fabian's arguments make a lot of sense.
However, if Timo *really wants* to start SQL on top of Table, that is what
he will do a great job at :-) As usual, we can keep it in beta status in
flink-staging until it is mature... and it will help create issues for the
Table API and give directio
IMO, it is better to have one feature that is reasonably well developed
instead of two half-baked features. That's why I proposed to advance the
Table API a bit further before starting the next big thing. I played around
with the Table API recently and I think it definitely needs a bit more
contrib
I see no reason why a SQL interface cannot be "bootstrapped" concurrently.
It would initially not support many operations,
but would act as a good source to test and drive functionality from the
Table API.
@Ted:
I would like to learn a bit more about the stack and internal abstractions
of Drill.
I didn't know that paper... Thanks for sharing.
I've worked on a SQL layer for Stratosphere some time ago, using Apache
Calcite (called Optiq back then). I think the project provides a lot of
very good tooling for creating a SQL layer. So if we decide to go for SQL
on Flink, I would suggest to us
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.
On Tue, May 26, 2015 at 12:52 PM, Fabian Hueske wrote:
> Hi,
>
> Flink's Table API is pretty close to what SQL provides. IMO, the best
> approach woul
Hi,
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
11 matches
Mail list logo
