Any opinions on whether we should formalize into some kind of release
verification step (manual or automatic)?
On Thu, Dec 2, 2021 at 5:22 PM Julian Hyde wrote:
> It’s quite easy to script. For example,
>
> git checkout calcite-1.27.0
> ./gradlew dependencies > /tmp/d27.txt
> git checkout
-1
I’m happy with the status quo.
> On Dec 3, 2021, at 9:34 AM, Vladimir Sitnikov
> wrote:
>
> Hi,
>
> Let us have a vote for PR-centric workflow for Calcite.
>
> [ ] +1, let's move to GitHub PRs/Issues for change management.
> [ ] -1, keep using JIRA because,
>
> Here's my vote:
> +1
What if RelNode.accept(RelShuttle) was deprecated and the RelShuttleImpl
had an if(node instanceof Logical*Node) instead?
I am against further enhancing RelNode.accept(RelShuttle), because, as
Vladimir pointed out, it does not actually follow a visitor pattern(aka
walking the tree) and fixing
I think this thread has forked into two distinct topics:
1. A general discussion of the utility of visitors
2. Support for generic return type for RelShuttle (the original purpose
of the thread)
My quick thoughts on #1: I've historically used the visitors in Calcite
extensively
Hi,
Let us have a vote for PR-centric workflow for Calcite.
[ ] +1, let's move to GitHub PRs/Issues for change management.
[ ] -1, keep using JIRA because,
Here's my vote:
+1 (binding), let's move to GitHub PRs/Issues for change management.
Note: dev@calcite keeps as is. I do not suggest
Update: in my case, the easiest way to unblock the situation was following
suggestion #2 from Jacques ("Write a concrete class that implements the
declared interface").
On Fri, Dec 3, 2021 at 8:58 AM Ruben Q L wrote:
> Hello,
>
> Julian, I find myself in a similar position. I upgraded into
Thank you for your reply. It is very helpful to me about the procedure of
how to merge the PR. Actually, I have tested in another git repository
before. I want to find a "standard procedure" to guarantee What I do is
the right procedure. I believe this email will help the new Committer who
is not
Hello,
Many guidelines about how to do something, including merging pull requests
[1] can be found on the Calcite website.
Best,
Stamatis
[1] https://calcite.apache.org/docs/howto.html#merging-pull-requests
On Fri, Dec 3, 2021 at 4:42 AM Jing Zhang wrote:
> Hi Xiong,
> Congratulations to be
Aleksey Plekhanov created CALCITE-4923:
--
Summary: Expand "star" for NATURAL JOIN fails if some columns are
filtered out by addToSelectList
Key: CALCITE-4923
URL:
Hello,
Julian, I find myself in a similar position. I upgraded into Calcite 1.28
in a certain project. This project had several custom rules, which (due to
the rule config refactoring [1], [2], [3]) now use some deprecated elements
(e.g. RelRule#Config#EMPTY). Recently I tried to adapt my rules
Aleksey Plekhanov created CALCITE-4922:
--
Summary: Unqualified common column in ORDER BY fails for JOINs
with USING and for NATURAL JOINs
Key: CALCITE-4922
URL:
Aleksey Plekhanov created CALCITE-4921:
--
Summary: Nested NATURAL JOINs or JOINs with USING can't find
common column
Key: CALCITE-4921
URL: https://issues.apache.org/jira/browse/CALCITE-4921
12 matches
Mail list logo
