Re: Enable "squash and merge" button in GitHub UI

I wonder if that has already been fixed. What do you think if I temporary enable the button, try it with https://github.com/apache/calcite/pull/2628 and then either keep the button or add a comment to asf.yaml? Vladimir

Re: [DISCUSS] JIRA vs GitHub Issues

For what it’s worth, I actually prefer JIRA’s workflow model. I strongly believe that people should log a JIRA case before starting work on a bug or feature. Then discussion can happen before coding starts. And I like making holistic reviews - reviewing the whole change, its goals, its impact,

Re: [DISCUSS] JIRA vs GitHub Issues

Julian, it looks like you have not been using GitHub for the past 5 years, and you miss a lot of improvements. GitHub allows a superset of what we do in JIRA, so I really can't understand why do you suggest enforcing JIRA. None of what you say sounds like a "good point to keep using JIRA", and

Re: [DISCUSS] Writing rules in dependent projects without depending on Immutables

>Has anyone else run into this problem? I've no idea how hard it would be to solve, however, it looks like something worth doing. It would be sad to require everyone to add annotation processors to their builds. Vladimir

Re: Enable "squash and merge" button in GitHub UI

>I've never experienced this with other (non-Apache) projects. https://github.com/JetBrains/kotlin-wrappers/pull/969 git show --format=full a3ff898f4f4e36d5a8bba9c1cbbefa924a9f5386 => commit a3ff898f4f4e36d5a8bba9c1cbbefa924a9f5386 Author: Victor Turansky Commit: GitHub :( Vladimir

Re: Enable "squash and merge" button in GitHub UI

Where/why is it lost? I've never experienced this with other (non-Apache) projects. On Thu, Dec 2, 2021 at 2:32 PM Vladimir Sitnikov < sitnikov.vladi...@gmail.com> wrote: > Thanks for the pointers. The committer info is lost indeed. > I would add the comments to asf.yaml so we can re-iterate

Re: Enable "squash and merge" button in GitHub UI

Author is retained there. It's not set to the person who merged the PR. On Thu, Dec 2, 2021 at 2:58 PM Vladimir Sitnikov < sitnikov.vladi...@gmail.com> wrote: > >I've never experienced this with other (non-Apache) projects. > > https://github.com/JetBrains/kotlin-wrappers/pull/969 > > git show

Re: Enable "squash and merge" button in GitHub UI

Hello all, We enabled the squash and merge feature in our github repo (Apache Drill) about a year ago. Prior to that we were requiring all PR authors to squash all commits prior to merging. It made our lives a bit easier as there were A LOT fewer mistakes when people would squash commits and

Re: Enable "squash and merge" button in GitHub UI

We have many committers, and it might make sense to keep track of who commits what. Squash and merge behaviour changed in 2020 :( https://github.community/t/authorship-of-merge-commits-made-by-github-apps-changed/2971/33 Vladimir

Re: [DISCUSS] Writing rules in dependent projects without depending on Immutables

Hey Julian, To me, there are currently three avenues I envisioned for extension project use: 1. Use the Immutable project or similar alternatives (e.g. [1]) 2. Write a concrete class that implements the declared interface. 3. Use a record metaphor appropriate to the environment you're in that

[DISCUSS] Writing rules in dependent projects without depending on Immutables

I’m trying to write a planner rule in a dependent project. (What what it’s worth, the project is not open source, and is implemented in Kotlin.) I don’t want to make the dependent project depend on the Immutables library, because that introduces an annotation processor and might destabilize our

Re: Enable "squash and merge" button in GitHub UI

Thanks for the pointers. The committer info is lost indeed. I would add the comments to asf.yaml so we can re-iterate later. Vladimir

Re: Feedback on a generic return type version of RelShuttle?

Steven>Look at the examples in the wikipedia page you link to Let me please copy Wikipedia for you. I agree it is not that easy to spot, however, please pay attention to Car#accept method. class Car { ... @Override public void accept(CarElementVisitor visitor) { for (CarElement

Re: Feedback on a generic return type version of RelShuttle?

Steven, James, >there are 22 implementations of RelShuttleImpl(excluding tests) 14 of them are RelHomogeneousShuttle subclasses. RelHomogeneousShuttle redirects all customized visit methods into a single visit(RelNode) method. That means Calcite has only 6 usages (!) of the "visitor" feature,

Re: Enable "squash and merge" button in GitHub UI

There was a discussion on why it was disabled but can't find the link at the moment. I know that by using this button the committer information is lost (replaced by GitHub). Hive is making use of it and the commit logs looks like below: commit a8e50734e0460e506f1762fbe0f628bcb444b8f5 Author:

Re: Feedback on a generic return type version of RelShuttle?

Steven>Agree with James, and that's not even including implementations in other Steven>codebases that use calcite (e.g. there are dozens of implementations in Steven>Dremio's codebase). Can you please show RelShuttle in Dremio codebase? I see no RelShuttle implementations:

Re: Feedback on a generic return type version of RelShuttle?

Agree with James, and that's not even including implementations in other codebases that use calcite (e.g. there are dozens of implementations in Dremio's codebase). On Thu, Dec 2, 2021 at 9:38 AM James Starr wrote: > Vladimir, there are 22 implementations of RelShuttleImpl(excluding tests) > in

Re: Enable "squash and merge" button in GitHub UI

Here is the previous discussion: https://lists.apache.org/thread/sjl40ts0mmkbpxbcvnyfzxcytvvsy82c Best, Stamatis On Thu, Dec 2, 2021 at 7:21 PM Stamatis Zampetakis wrote: > There was a discussion on why it was disabled but can't find the link at > the moment. > I know that by using this button

Re: Feedback on a generic return type version of RelShuttle?

I don't really understand what you are trying to say. An accept() method in the classes on which visitor operates is a standard, normal part of the visitor pattern. Look at the examples in the wikipedia page you link to. I think the accept() method is necessary for compile time binding to work.

Re: Feedback on a generic return type version of RelShuttle?

Vladimir, there are 22 implementations of RelShuttleImpl(excluding tests) in calcite core. That hardly seems like no value add. I am not sure why RelNode.visit needs to exist though, the dispatch could simply be done in some method internal to the visitor/shuttle. On Thu, Dec 2, 2021 at 2:07 AM

Enable "squash and merge" button in GitHub UI

Hi, I see "squash and merge" is not enabled in GitHub. I am going to enable it soon, so we can merge PRs as single-commit changes, and we no longer ask contributors to "squash changes" manually. I've no idea why the button was disabled. See https://github.com/apache/calcite/pull/2629 Vladimir

[jira] [Created] (CALCITE-4918) Add a VARIANT data type

Julian Hyde created CALCITE-4918: Summary: Add a VARIANT data type Key: CALCITE-4918 URL: https://issues.apache.org/jira/browse/CALCITE-4918 Project: Calcite Issue Type: Bug

[jira] [Created] (CALCITE-4919) Add a function to parse a JSON string into a VARIANT object

Julian Hyde created CALCITE-4919: Summary: Add a function to parse a JSON string into a VARIANT object Key: CALCITE-4919 URL: https://issues.apache.org/jira/browse/CALCITE-4919 Project: Calcite

Re: [GITHUB-HELP] The Committer how to merge a PR correctly

Did you search for an answer before posting this question? What did you find? > On Dec 2, 2021, at 5:24 PM, xiong duan wrote: > > Hi, PMC and Committers. As a newcomer, I have one problem want to know. > > Do we have a procedure about The Committer how to merge a PR correctly? > > Every time

[GITHUB-HELP] The Committer how to merge a PR correctly

Hi, PMC and Committers. As a newcomer, I have one problem want to know. Do we have a procedure about The Committer how to merge a PR correctly? Every time I merge the PR, I always worried whether have a wrong step. So If have the standard procedure, It will be very helpful.

[jira] [Created] (CALCITE-4920) Introduce logical space pruning to TopDownRuleDriver

Jinpeng Wu created CALCITE-4920: --- Summary: Introduce logical space pruning to TopDownRuleDriver Key: CALCITE-4920 URL: https://issues.apache.org/jira/browse/CALCITE-4920 Project: Calcite Issue

Re: Enable "squash and merge" button in GitHub UI

It definitely makes sense to track who commits what. We want to give credit to active committers! To see the committer, I use ‘--format=fuller’, e.g. $ git --format=fuller origin/master commit 7c423ef23878271b1c50c03629ebfff674985681 Author: huzhe AuthorDate: Sun Nov 14 11:27:55

Re: Snowflake VARIANT support

Work has not started, and I don’t know of anyone who is planning to work on this. I have logged https://issues.apache.org/jira/browse/CALCITE-4918 and https://issues.apache.org/jira/browse/CALCITE-4919

Re: [DISCUSS] Writing rules in dependent projects without depending on Immutables

Thanks for the prompt reply, Jacques. I’ll explore your suggestions and let you know what I find. > On Dec 2, 2021, at 1:33 PM, Jacques Nadeau wrote: > > Hey Julian, > > To me, there are currently three avenues I envisioned for extension project > use: > 1. Use the Immutable project or

Re: [GITHUB-HELP] The Committer how to merge a PR correctly

Hi Xiong, Congratulations to be a committer of Calcite. I'm not a Calcite committer. However I could share the PR merge workflow which I get from a PMC member of Apache Flink community. Maybe it could help you. 1. get the PR in your local repository --- > git fetch pull//head:

Re: Feedback on a generic return type version of RelShuttle?

@Walaa Eldin Moustafa , for RexNodes there seems to be already this "generic return type visitor pattern" via RexVisitor; in fact, RexShuttle is just an implementation of RexVisitor. On Thu, Dec 2, 2021 at 9:06 AM Walaa Eldin Moustafa wrote: > +1 while maintaining backward compatibility. Is

Re: Feedback on a generic return type version of RelShuttle?

You are right! Always used RexShuttle directly. To make it parallel, we could have named the new Rel class RelVisitor, but RelVisitor is already taken. On Thu, Dec 2, 2021 at 1:16 AM Ruben Q L wrote: > @Walaa Eldin Moustafa , for RexNodes there seems > to be already this "generic return type

Re: Feedback on a generic return type version of RelShuttle?

Sounds like a good idea, as long as it does not break backwards compatibility. Regards, Ruben On Thu, Dec 2, 2021 at 7:22 AM Jay Narale wrote: > ＋1 re-writing to other types would be easier with this > > On Thu, Dec 2, 2021 at 16:18 Alessandro Solimando < > alessandro.solima...@gmail.com>

Re: Contributor role request

Hello, Michael Thank you! -- Regards, Konstantin Orlov

Re: Feedback on a generic return type version of RelShuttle?

+1 while maintaining backward compatibility. Is there a plan for RexShuttle too? On Thu, Dec 2, 2021 at 1:03 AM Ruben Q L wrote: > Sounds like a good idea, as long as it does not break backwards > compatibility. > > Regards, > Ruben > > On Thu, Dec 2, 2021 at 7:22 AM Jay Narale wrote: > > > ＋1

Re: Feedback on a generic return type version of RelShuttle?

I've no issues with making the existing visitor more generic, however, the choice of accept methods seems arbitrary :-/ Would it help if we move or prefer using algebras rather than visitors? https://oleksandrmanzyuk.wordpress.com/2014/06/18/from-object-algebras-to-finally-tagless-interpreters-2/

[jira] [Created] (CALCITE-4916) Need more exception information about "Non-query expression encountered in illegal context"

xuyang created CALCITE-4916: --- Summary: Need more exception information about "Non-query expression encountered in illegal context" Key: CALCITE-4916 URL: https://issues.apache.org/jira/browse/CALCITE-4916

[jira] [Created] (CALCITE-4917) Add test for 'IS NOT NULL(a) AND a=b' simplifies to "a=b" for UnknownAsFalse semantics

Alessandro Solimando created CALCITE-4917: - Summary: Add test for 'IS NOT NULL(a) AND a=b' simplifies to "a=b" for UnknownAsFalse semantics Key: CALCITE-4917 URL: