Re: [DISCUSS] State of the project 2019

Hi everyone, Actually i think it's time to have my say after receiving the email titiled `Have your say!` from Julian Hyde. As a person new this project, i am appreciated community's help for my question ml, and glad to see its communnity so active and harmonious. Other than that, it also

Re: [DISCUSSION] Extension of Metadata Query

I agree with Danny. We should believe that uses can handle it well. Best, Chunwei On Tue, Oct 22, 2019 at 3:26 PM Danny Chan wrote: > > I don’t trust the typical Calcite user to be able to write a sub-class > that works correctly and efficiently. > > People who sub-class RelMetadataQuery are

Calcite-Master - Build # 1383 - Failure

The Apache Jenkins build system has built Calcite-Master (build #1383) Status: Failure Check console output at https://builds.apache.org/job/Calcite-Master/1383/ to view the results.

Re: [DISCUSS] State of the project 2019

Thank you for your great work, Francis! In the past year, I deeply feel that Calcite community is becoming more and more active, which means that more and more companies start to use Apache Calcite. This is very exciting and encouraging. Thanks to active contributions and committers, pull

Re: [DISCUSS] State of the project 2019

Thanks for the state summarize Francis Chuang ! And thanks for the awesome work for keeping Calcite in good shape ! From my perspective, I really feel that Calcite is becoming more and more popular and there are many new groups trying to use this great project, as a reviewer, I saw many

Re: [QUESTION] One query executed on two or more different data storages through Calcite

my intuition is leave the plans alone. when actually execute the TABLESCAN PLAN, send it to two targets. refer to the csv example. On Tue, Oct 22, 2019 at 9:26 PM Juan Pan wrote: > Hi Danny and Julian > > > Thanks, i did some researches after listened to your suggestions. It seems > not an easy

[jira] [Created] (CALCITE-3438) Validator should disallow use of the GROUPING function inside a FILTER clause

Julian Hyde created CALCITE-3438: Summary: Validator should disallow use of the GROUPING function inside a FILTER clause Key: CALCITE-3438 URL: https://issues.apache.org/jira/browse/CALCITE-3438

Re: [DISCUSS] State of the project 2019

+1 on the improvement of pull request turnaround time. I also see a few new committers who are really active. They help review PRs and answer mail list questions, which really benefits the community and people who’d like to make code contribution. I also feel like Calcite has big code base

Re: type casting or throw exception for unsupported type in SQL dialects in RelToSql

I would imagine this problem will appear when using one dialect or manual construct Rels and later try to do RelToSql to BigQuery. If directly parse from BigQuery by a way there shouldn't be a problem. -Rui On Tue, Oct 22, 2019 at 10:46 AM Julian Hyde wrote: > It’s very similar to

Have your say!

Everyone, please feel free to chime in on the “State of the project” thread. We welcome comments from people new the project — even people who have just been lurking until now — as much as from committers and PMC members. The “State of the project” is an annual discussion where we try to find

Re: Apache Calcite meetup group

Thanks for adding me as co-organizer Denis. I will be happy to work with you and other members of the community to organize meetups in Bay area. -Jesús On Tue, Oct 22, 2019 at 4:53 AM Alessandro Solimando < alessandro.solima...@gmail.com> wrote: > Hello, > despite not being able to contribute

Re: type casting or throw exception for unsupported type in SQL dialects in RelToSql

It’s very similar to https://issues.apache.org/jira/browse/CALCITE-3282 and the solution will be the same. Inside Calcite (e.g. in RexNode format), I suggest that you map BigQuery types onto standard SQL types where possible. For example,

type casting or throw exception for unsupported type in SQL dialects in RelToSql

Hi community, Recently I submitted a patch [1] to have a correct type converting to BigQuery dialect when there is a CAST in RelToSql. That patch left some cases unhandled, e.g. INTEGER. The reason is BigQuery does not support INTEGER or INT32, it only supports INT64. So the open question is, in

Re: [QUESTION] One query executed on two or more different data storages through Calcite

Hi Danny and Julian Thanks, i did some researches after listened to your suggestions. It seems not an easy thing for me, but i will learn Calcite and Flink more and think about your thoughts. Best wishes, Trista Juan Pan panj...@apache.org Juan Pan(Trista), Apache ShardingSphere On

Re: [QUESTION] One query executed on two or more different data storages through Calcite

In this case, you could rewrite your query to include a UNION and select data from the two sources together. That would likely be the easiest path forward. -- Michael Mior mm...@apache.org Le lun. 21 oct. 2019 à 22:36, Juan Pan a écrit : > > Hi everyone, > > > Thanks for your attention. I can

Re: Apache Calcite meetup group

Hello, despite not being able to contribute actively I keep following the ML and the project, I'd love to attend meetups here in Paris if any! Best regards, Alessandro On Tue, 22 Oct 2019 at 05:08, Julian Hyde wrote: > Best thing would be for you and Jesus to collaborate. Feel free to do it >

Re: [DISCUSSION] Extension of Metadata Query

>  I don’t trust the typical Calcite user to be able to write a sub-class that >works correctly and efficiently. People who sub-class RelMetadataQuery are almost those who has deep customization of the calcite-core, for example, the MaxCompute or the Apache Flink. We may assume that it is not