+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
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.
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
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
+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
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
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
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
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
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
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
+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:
>
+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
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."
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 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
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
Hey Chunwei!
about CALCITE-4118: I wanted to get back to it - but I was busy doing other
things...
The patch is not ready; it's wip branch is here:
https://github.com/kgyrtkirk/calcite/tree/4118-cast-varbinary
My plan was to figure out how to do it without writing down concreate
types(like
18 matches
Mail list logo
