Re: [DISCUSS] Default disable the RexNode normalization(or operands reorder)

2020-07-16 Thread Danny Chan
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

Re: [DISCUSS] Default disable the RexNode normalization(or operands reorder)

2020-07-16 Thread Vladimir Sitnikov
Danny, could you please add a test case for nestes normalization (see comment in pr) ? Vladimir

Re: [DISCUSS] Default disable the RexNode normalization(or operands reorder)

2020-07-16 Thread Danny Chan
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

[DISCUSS] Remove "final" from AbstractRelNode#getRelTypeName

2020-07-16 Thread Ruben Q L
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

Re: [DISCUSS] Binary files for testing InnoDB adapter

2020-07-16 Thread Michael Mior
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

Re: [DISCUSS] Remove "final" from AbstractRelNode#getRelTypeName

2020-07-16 Thread Haisheng Yuan
+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

Re: [DISCUSS] Remove "final" from AbstractRelNode#getRelTypeName

2020-07-16 Thread Rui Wang
+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: >

Re: [DISCUSS] Binary files for testing InnoDB adapter

2020-07-16 Thread Julian Hyde
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

Re: [DISCUSS] Remove "final" from AbstractRelNode#getRelTypeName

2020-07-16 Thread Julian Hyde
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

Re: [DISCUSS] Binary files for testing InnoDB adapter

2020-07-16 Thread Enrico Olivelli
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

Re: [DISCUSS] Remove "final" from AbstractRelNode#getRelTypeName

2020-07-16 Thread Ruben Q L
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

Re: [DISCUSS] Binary files for testing InnoDB adapter

2020-07-16 Thread Stamatis Zampetakis
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

Re: [DISCUSS] Remove "final" from AbstractRelNode#getRelTypeName

2020-07-16 Thread Rui Wang
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

Re: [DISCUSS] Remove "final" from AbstractRelNode#getRelTypeName

2020-07-16 Thread Stamatis Zampetakis
+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

Re: [ANNOUNCE] Apache Calcite Avatica Go 5.0.0 released

2020-07-16 Thread Stamatis Zampetakis
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

Re: [DISCUSS] Towards Calcite 1.24.0

2020-07-16 Thread Chunwei Lei
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

Calcite-Master - Build # 1840 - Failure

2020-07-16 Thread Apache Jenkins Server
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.

Re: [DISCUSS] Binary files for testing InnoDB adapter

2020-07-16 Thread Forward Xu
+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

Re: Calcite-Master - Build # 1840 - Failure

2020-07-16 Thread Hubert Zhang
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

Re: [DISCUSS] Towards Calcite 1.24.0

2020-07-16 Thread Julian Hyde
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

Re: [DISCUSS] Remove "final" from AbstractRelNode#getRelTypeName

2020-07-16 Thread Julian Hyde
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