TL;DR: https://github.com/apache/calcite/pull/1019 passes tests for
calcite-core, and it now fails Cassandra adapter test.
I'm inclined to try adding Map, Convention>
kind of registry.
Then Calcite would understand than operand(EnumerableProject.class)
means ENUMERABLE convention no matter what R
Thanks Julian!
> On Jan 30, 2019, at 6:32 PM, Julian Hyde wrote:
>
> Run the main method of org.apache.calcite.test.CoreQuidemTest (or one of the
> other sub-classes of QuidemTest) and pass the path of the script (e.g.
> “sql/agg.iq”) as the argument.
>
> You can also run CoreQuidemTest as a
Hi!
We are adding a new custom RelNode, that behaves a little bit like Aggregate
node and we are wondering how we should implement
RelNode#accept(org.apache.calcite.rex.RexShuttle)
Our node has a similar feature as Aggregate node, that it’s keying by the
incoming data. At first I thought that
Hi all,
There is a PR CALCITE-2791[1] from xuqianjin about adding a MySQL function
JSON_TYPE[2], and I want to know what do you think about it.
JSON_TYPE is not a standard JSON function defined by SQL:2016. In MySQL the use
of this function is to get the type of a JSON doc. The similar operat
Calcite needs to make regular releases, and we have established a cadence of
every 2 - 3 months that everyone seems to like. But to keep that running, each
release needs a release manager, and finding a release manager always seems to
be a chore.
I wonder if we have trouble recruiting release m
+1
In the reference doc, let’s make it clear that these are in MySQL but not in
the standard. (Unlike some of their other extensions to standard SQL, MySQL
seem to have done a good job - they are well-designed and well-documented.)
> On Jan 31, 2019, at 10:20 AM, Hongze Zhang wrote:
>
> Hi al
Nice document Hongze!
Since the functions are only present in MySQL why not create a
MySQLOperatorTable and put them there? I went over the discussion in
CALCITE-2791 but I did not understand why it is preferable to put them in
the SqlStdOperatorTable.
Στις Πέμ, 31 Ιαν 2019 στις 10:51 μ.μ., ο/η J
Still the primary goal of RelBuilderFactory is to create a RelBuilder. If
getConvetion does not have an impact on the created RelBuilder then this
behavior will be also confusing.
I like better your suggestion to verify traits at call#transformTo. Maybe
we could say that if RelOptRule#getOutTrait
Release Target date Release manager
=== === ===
1.192019-02
1.202019-04
1.212019-06Stamatis
1.222019-08
1.232019-10
Στις Πέμ, 31 Ιαν 2019 στις 7:46 μ.μ., ο/η Julian Hyde
έγραψε:
> Calcite needs to make regular releases, and we have established a ca
Thank you all for the warm welcome!
I hold a PhD on query optimization for massively parallel systems and I am
interested in anything around data management.
I am currently working on introducing relational algebra and SQL on a
multi-version database with various types of indexes which till now
@Kenneth:
A CannotPlanException indicates a bug either in the planner it self either
in the way that is initialised. As in every program there is no better way
to ensure that there no bugs other than testing. The correctness of the
VolcanoPlanner highly depends on the rules that are used since not
Release Target date Release manager
=== === ===
1.192019-02
1.202019-04
1.212019-06Stamatis
1.222019-08 Andrei
1.232019-10
On Thu, Jan 31, 2019 at 6:14 PM Stamatis Zampetakis
wrote:
> Release Target date Release manager
> === ===
hi Hongze Zhang??
This makes sense to me, which is why I added the json_type function in the
first place. Thank you very much.
best
qianjin
-- --
??: "Hongze Zhang";
: 2019??2??1??(??) 2:20
??: "dev@calcite.apache.org";
???
The Apache Jenkins build system has built Calcite-Master (build #1005)
Status: Failure
Check console output at https://builds.apache.org/job/Calcite-Master/1005/ to
view the results.
Welcome, Stamatis, and thanks for your help.
On Thu, Jan 31, 2019 at 6:22 PM Stamatis Zampetakis
wrote:
> Thank you all for the warm welcome!
>
>
> I hold a PhD on query optimization for massively parallel systems and I am
> interested in anything around data management.
>
>
> I am currently wor
Welcome, Zoltan!
On Wed, Jan 30, 2019 at 4:39 PM Francis Chuang
wrote:
> Congrats, Zoltan!
>
> Francis
>
> On 31/01/2019 7:05 am, Kevin Risden wrote:
> > Congrats and welcome Zoltan!
> >
> > Kevin Risden
> >
> > On Wed, Jan 30, 2019 at 2:55 PM Enrico Olivelli
> wrote:
> >>
> >> Congrats!
> >>
>
Hi Stamatis,
Thanks for mentioning MySQLOperatorTable!
I just read some code about the usage of OracleOperatorTable in Calcite, but I
am now not strongly inclined to add MySQL's JSON functions to
MySQLOperatorTable.
MySQL's JSON functions are rarely conflict with what are from standard, and
th
Congratulations, Zoltan!
Hongze
From: Andrei Sereda
Date: 2019-02-01 11:14
To: dev
Subject: Re: [ANNOUNCE] New committer: Zoltan Haindrich
Welcome, Zoltan!
On Wed, Jan 30, 2019 at 4:39 PM Francis Chuang
wrote:
> Congrats, Zoltan!
>
> Francis
>
> On 31/01/2019 7:05 am, Kevin Risden wrote:
Congratulations, Stamatis!
Hongze
From: Andrei Sereda
Date: 2019-02-01 11:13
To: dev
Subject: Re: [ANNOUNCE] New committer: Stamatis Zampetakis
Welcome, Stamatis, and thanks for your help.
On Thu, Jan 31, 2019 at 6:22 PM Stamatis Zampetakis
wrote:
> Thank you all for the warm welcome!
>
>
hi statmatis:
It's also possible that we could do better in both ways, as Hongze Zhang said.
One of the initial reasons I implemented json_type was to use it in flink as
well. However, we know that flink is not open to support a dialect like mysql.
best
qianjin
-- 原始邮件 --
Congratulations, Stamatis!
best
qianjin
-- 原始邮件 --
发件人: "Hongze Zhang";
发送时间: 2019年2月1日(星期五) 中午1:11
收件人: "dev@calcite.apache.org";
主题: Re: Re: [ANNOUNCE] New committer: Stamatis Zampetakis
Congratulations, Stamatis!
Hongze
From: Andrei Sereda
Date: 2019-
Congratulations, Zoltan!
best
qianjin
-- --
??: "Hongze Zhang";
: 2019??2??1??(??) 1:10
??: "dev@calcite.apache.org";
: Re: Re: [ANNOUNCE] New committer: Zoltan Haindrich
Congratulations, Zoltan!
Hongze
From: Andrei
22 matches
Mail list logo
