I would commit the PR soon because I want this into 1.24 release, we can
continue the discussion though ~
Best,
Danny Chan
在 2020年7月16日 +0800 PM2:53,Vladimir Sitnikov ,写道:
> > But currently AND/OR in Calcite is always binary operator
>
> I guess we might want to add multi-arg AND in the future to
Danny, could you please add a test case for nestes normalization (see
comment in pr) ?
Vladimir
I added and it passed.
Best,
Danny Chan
在 2020年7月16日 +0800 PM4:35,Vladimir Sitnikov ,写道:
> Danny, could you please add a test case for nestes normalization (see
> comment in pr) ?
>
> Vladimir
Hello everyone,
I have a small issue regarding RelNode#getRelTypeName [1]. This method is
used when explaining a plan (e.g. via RelOptUtil#dumpPlan), and it "returns
the name of this relational expression's class, sans package name, for use
in explain".
This method has a *final* implementation in
I don't personally have a problem with this, but it seems as though it
might violate the release policy. Specifically the statement "It is
also necessary for the PMC to ensure that the source package is
sufficient to build any binary artifacts associated with the release."
https://www.apache.org/l
+1 to remove final.
The method returns the logical/physical operator name. When we explain the plan
(and compute the digest in 1.23.0 and before), getRelTypeName may be called
multiple times for a single operator, every time it will start from scratch to
figure out what is correct operator name
+1 to make getRelTypeName overridable.
Not a java language expert, to me when there are cases that a public API
with final cannot solve, it's a good sign to remove that final to allow
customization to solve those specific use cases.
-Rui
On Thu, Jul 16, 2020 at 8:58 AM Haisheng Yuan wrote:
>
Michael,
I think that sentence covers the situation where, say, we ship a
.class file without shipping the .java it was generated from.
In our case, we are shipping the equivalent of the .class file and the
.java file (namely EMP.ibd and the scott.sql that MySQL generated it
from). We have to shi
I don't have a problem with this change.
I do have a problem with changes, such as the one that Ruben recently
committed [1] to make the constructor of EnumerableMergeJoin, that
increase the surface of our public API. The larger our public API, the
more work it is to add features to Calcite while
Il Gio 16 Lug 2020, 21:28 Julian Hyde ha scritto:
> Michael,
>
> I think that sentence covers the situation where, say, we ship a
> .class file without shipping the .java it was generated from.
>
> In our case, we are shipping the equivalent of the .class file and the
> .java file (namely EMP.ibd
Thanks for the feedback, I will create a Jira ticket to carry out the
change and remove the "final" from AbstractRelNode#getRelTypeName.
@Julian, I am sorry I committed that change (
https://issues.apache.org/jira/browse/CALCITE-4123) without further
discussion. I honestly thought it was a minor d
Hello,
It's good to avoid non-readable files when possible but I don't think we
have to worry too much about it.
The ASF foundation does not require all files in a release to be
protected by copyright law and lists a few exceptions [1].
The file is a database dump so I don't see much creativity
Since the concern on CALCLITE-4123 is brought up, can we make a quick
decision about whether to make it in the 1.24.0 release or not?
Having the public interface increased in 1.24.0 and then later there might
be a decision to revert it doesn't sound right. If we are not sure for now,
maybe have a
+1 for removing the final modifier for all the reasons mentioned so far.
Regarding CALCITE-4123, I find Ruben's justification convincing.
The majority of Enumerable operators (not only joins) are extensible (with
public/protected constructors) so it seems that EnumerableMergeJoin was the
only exce
Many thanks Francis and all the people involved!
On Thu, Jul 16, 2020 at 3:56 AM Francis Chuang
wrote:
> The Apache Calcite team is pleased to announce the release of Apache
> Calcite Avatica Go 5.0.0.
>
> Avatica is a framework for building database drivers. Avatica
> defines a wire API and ser
Hi, Zoltan. Thank you for your reply.
Regarding CALCITE-4118, I would like to try to fix it.
Best,
Chunwei
On Thu, Jul 16, 2020 at 2:08 PM Zoltan Haindrich wrote:
> Hey Chunwei!
>
> about CALCITE-4118: I wanted to get back to it - but I was busy doing
> other things...
> The patch is not re
The Apache Jenkins build system has built Calcite-Master (build #1840)
Status: Failure
Check console output at https://builds.apache.org/job/Calcite-Master/1840/ to
view the results.
+1
If we can add the function(Example: innodb-java-writer) of generating ibd
files in the next version, I think it will be better. In this way, InnoDB
adapter initially has the capability of a database, and can further improve
the current unit test.
best
Forward
Stamatis Zampetakis 于2020年7月1
dev-unsubscr...@calcite.apache.org
From: Apache Jenkins Server
Sent: 17 July 2020 10:24
To: dev@calcite.apache.org
Subject: Calcite-Master - Build # 1840 - Failure
The Apache Jenkins build system has built Calcite-Master (build #1840)
Status: Failure
Check con
Chunwei,
I think you said you'd have an RC in the middle of this week. In my
opinion, you should hold to that. There will always be one or two last
bugs that don't make it into a release. No matter - they'll be in the
next one.
For example, I've been trying to get the InnoDB adapter (
https://iss
When I write an API and do not include the word 'protected' on a
constructor I am saying 'this is not a public API'. So someone coming
along and adding the word 'protected' is actually making a big change.
There are other ways to extend code than sub-classing. I don't know
what use case Ruben has
21 matches
Mail list logo