Re: Errored: apache/calcite#12834 (main - 94dc303)

[Francis Chuang]

Looking at the jobs on GH actions, I don't think we are testing all the 
OpenJDK versions that are being tested on Travis: 
https://github.com/apache/calcite/actions/runs/2551147939


I think over there's some drift between the Travis and GH Actions config 
and they are not exactly equivalent / testing the same things.


On 24/06/2022 9:05 am, Julian Hyde wrote:

Does anyone have any idea why Travis failed for me? I pushed a one-line commit 
that had already succeeded in GitHub actions.

Julian
  




On Jun 23, 2022, at 3:54 PM, Travis CI  wrote:

apache / calcite 

main 
Build #12834 has errored 
16
 mins and 43 secs
Sergey Nuyanzin94dc303 CHANGESET → 

[CALCITE-5196] Bump apiguardian to 1.1.2
Want to know about upcoming build environment updates?

Would you like to stay up-to-date with the upcoming Travis CI build environment 
updates? We set up a mailing list for you!

SIGN UP HERE 
  Documentation  about Travis CI
Have any questions? We're here to help. 
Unsubscribe 

 from build emails from the apache/calcite repository.
To unsubscribe from all build emails, please update your settings 
.
  
Travis CI GmbH, Bonner Straße 12, 51379 Leverkusen, Germany | GF/CEO: Randy Jacops | 
Contact: cont...@travis-ci.com  | Amtsgericht 
Charlottenburg, Berlin, HRB 108397 | Umsatzsteuer-ID gemäß §27 a Umsatzsteuergesetz: 
DE282002648

Re: Errored: apache/calcite#12834 (main - 94dc303)

[Julian Hyde]

This is a problem on the Travis side, right? I can’t see how this one-line 
change could have broken anything.

> On Jun 23, 2022, at 4:10 PM, Francis Chuang  wrote:
> 
> It seems to be an issue with the open jdk version:
> 
> Expected feature release number in range of 9 to , but got: 15 => error for 
> OpenJDK 15
> Expected feature release number in range of 9 to , but got: 18 => error for 
> OpenJDK 18
> 
> 
> On 24/06/2022 9:05 am, Julian Hyde wrote:
>> Does anyone have any idea why Travis failed for me? I pushed a one-line 
>> commit that had already succeeded in GitHub actions.
>> Julian
>>  
>>> On Jun 23, 2022, at 3:54 PM, Travis CI  wrote:
>>> 
>>> apache / calcite 
>>> 
>>> main 
>>> Build #12834 has errored 
>>> 16
>>>  mins and 43 secs
>>> Sergey Nuyanzin94dc303 CHANGESET → 
>>> 
>>> [CALCITE-5196] Bump apiguardian to 1.1.2
>>> Want to know about upcoming build environment updates?
>>> 
>>> Would you like to stay up-to-date with the upcoming Travis CI build 
>>> environment updates? We set up a mailing list for you!
>>> 
>>> SIGN UP HERE 
>>>  Documentation  about Travis CI
>>> Have any questions? We're here to help. 
>>> Unsubscribe 
>>> 
>>>  from build emails from the apache/calcite repository.
>>> To unsubscribe from all build emails, please update your settings 
>>> .
>>>  
>>> Travis CI GmbH, Bonner Straße 12, 51379 Leverkusen, Germany | GF/CEO: Randy 
>>> Jacops | Contact: cont...@travis-ci.com  | 
>>> Amtsgericht Charlottenburg, Berlin, HRB 108397 | Umsatzsteuer-ID gemäß §27 
>>> a Umsatzsteuergesetz: DE282002648

Re: Errored: apache/calcite#12834 (main - 94dc303)

[Francis Chuang]

It seems to be an issue with the open jdk version:

Expected feature release number in range of 9 to , but got: 15 => error 
for OpenJDK 15
Expected feature release number in range of 9 to , but got: 18 => error 
for OpenJDK 18



On 24/06/2022 9:05 am, Julian Hyde wrote:

Does anyone have any idea why Travis failed for me? I pushed a one-line commit 
that had already succeeded in GitHub actions.

Julian
  




On Jun 23, 2022, at 3:54 PM, Travis CI  wrote:

apache / calcite 

main 
Build #12834 has errored 
16
 mins and 43 secs
Sergey Nuyanzin94dc303 CHANGESET → 

[CALCITE-5196] Bump apiguardian to 1.1.2
Want to know about upcoming build environment updates?

Would you like to stay up-to-date with the upcoming Travis CI build environment 
updates? We set up a mailing list for you!

SIGN UP HERE 
  Documentation  about Travis CI
Have any questions? We're here to help. 
Unsubscribe 

 from build emails from the apache/calcite repository.
To unsubscribe from all build emails, please update your settings 
.
  
Travis CI GmbH, Bonner Straße 12, 51379 Leverkusen, Germany | GF/CEO: Randy Jacops | 
Contact: cont...@travis-ci.com  | Amtsgericht 
Charlottenburg, Berlin, HRB 108397 | Umsatzsteuer-ID gemäß §27 a Umsatzsteuergesetz: 
DE282002648

Re: Errored: apache/calcite#12834 (main - 94dc303)

[Julian Hyde]

Does anyone have any idea why Travis failed for me? I pushed a one-line commit 
that had already succeeded in GitHub actions.

Julian
 


> On Jun 23, 2022, at 3:54 PM, Travis CI  wrote:
> 
> apache / calcite 
> 
> main 
> Build #12834 has errored 
> 16
>  mins and 43 secs
> Sergey Nuyanzin94dc303 CHANGESET → 
> 
> [CALCITE-5196] Bump apiguardian to 1.1.2
> Want to know about upcoming build environment updates?
> 
> Would you like to stay up-to-date with the upcoming Travis CI build 
> environment updates? We set up a mailing list for you!
> 
> SIGN UP HERE 
>  Documentation  about Travis CI
> Have any questions? We're here to help. 
> Unsubscribe 
> 
>  from build emails from the apache/calcite repository.
> To unsubscribe from all build emails, please update your settings 
> .
>  
> Travis CI GmbH, Bonner Straße 12, 51379 Leverkusen, Germany | GF/CEO: Randy 
> Jacops | Contact: cont...@travis-ci.com  | 
> Amtsgericht Charlottenburg, Berlin, HRB 108397 | Umsatzsteuer-ID gemäß §27 a 
> Umsatzsteuergesetz: DE282002648

Re: PR Review Request

[Julian Hyde]

+1 to Stamatis’ idea. It won’t make things worse. :)

But to repeat what I said earlier. We need existing committers to pull their 
weight. If necessary, committers need to talk to their managers and get time 
allocated to contribute to “housekeeping”.

One important kind of housekeeping is productization. That means not just 
getting features and bug fixes into Calcite, but adding sufficient 
documentation that users know they exist and how to use them. You may have 
noticed that I spend a lot of effort asking people to improve the subject and 
description of JIRA cases, and making sure that the commit message matches the 
JIRA subject. I do this because usually the only documentation of a feature is 
the line in the release notes and the JIRA case it links to.

This effort is key to Calcite’s success, and quite a few committers don’t do 
it. If committers did a better job in this area, it would reduce the workload 
on me.

Julian



> On Jun 23, 2022, at 6:44 AM, Ruben Q L  wrote:
> 
> +1 on Stamatis' idea, I think it could help with the current situation of
> lack of reviewers.
> 
> Best,
> Ruben
> 
> 
> On Thu, Jun 23, 2022 at 12:56 PM Charles Givre  wrote:
> 
>> Hello all,
>> FWIW, If a committer/reviewer shortage is the issue, I'd second Stamatis's
>> recommendation.
>> Best,
>> -- C
>> 
>>> On Jun 23, 2022, at 7:02 AM, Stamatis Zampetakis 
>> wrote:
>>> 
>>> Hi all,
>>> 
>>> How about granting Calcite committership to people who are already ASF
>>> committers (in other projects) and they have a proven record of working
>>> with Calcite?
>>> 
>>> Usually the PMC invites people to become committers to the project after
>>> having a few successful code contributions in Calcite/Avatica repos.
>>> This is to ensure that people are familiar with the codebase and
>> understand
>>> how the ASF works.
>>> 
>>> People who are already committers in an ASF project already know how the
>>> foundation works and how they should behave.
>>> Also people working in projects like Drill, Flink, Hive, Ignite, Phoenix,
>>> etc., may already be quite familiar with Calcite if they have worked on
>> the
>>> query processing layer of the system.
>>> 
>>> It might be difficult for the Calcite PMC to identify people familiar
>> with
>>> Calcite if they don't contribute to the main Calcite/Avatica repos
>>> regularly thus I would be open to consider people for committers on a per
>>> request basis.
>>> 
>>> Example:
>>> Bob is an ASF committer in Flink and he has pushed various contributions
>>> around Calcite in the Flink repo.
>>> Bob feels confident about fixing trivial things in Calcite and he wants
>> to
>>> help with reviewing and merging open PRs.
>>> Bob sends an email to private@calcite list requesting to become a
>> Calcite
>>> committer.
>>> Bob explains in the email who he is and what he has done to demonstrate
>> he
>>> is familiar with the Calcite code.
>>> The Calcite PMC acknowledges the request and starts a vote for granting
>>> Calcite comittership to Bob.
>>> The Calcite PMC informs Bob about their decision and takes further
>> actions
>>> if necessary.
>>> 
>>> If we agree on the overall idea we can figure out the details and
>> formalize
>>> the request process in our docs.
>>> 
>>> Best,
>>> Stamatis
>>> 
>>> On Thu, Jun 23, 2022 at 6:06 AM Jing Zhang  wrote:
>>> 
 Hi everyone,
 
 This is an awesome discussion to improve collaborating between different
 projects.
 Thanks Julian, Jacques, Austin, Martijn, Timo's effort to make it
>> happen.
 
 Best,
 Jing Zhang
 
 Martijn Visser  于2022年6月23日周四 01:43写道：
 
> Hi Jacques, Julian, Austin and everyone else,
> 
> Thank you very much for sharing all your experiences and providing
>> really
> valuable input. I'll definitely relay this back to the original
 discussion
> thread in the Flink community. Part of bringing this information back
>> to
> the Flink community is also because I feel like the only way that
 different
> OSS solutions can help each other forward is by communicating and
> collaborating. As Timo already mentioned, he'll try to help out. Let's
 try
> to get some more involved.
> 
> Side note: I also saw that this thread got some traction on Twitter [1]
 on
> the cost of forking.
> 
> Best regards,
> 
> Martijn
> 
> [1]
> 
> 
 
>> https://twitter.com/gunnarmorling/status/1539499415337111553?s=21=8fGk3PxScOx4FJPJWE5UeA
> 
> Op wo 22 jun. 2022 om 09:29 schreef Timo Walther :
> 
>> Hi everyone,
>> 
>> This is a really great discussion. Thanks for starting it Martijn and
>> your input Jacques! I have been fighting against forking Calcite in
>> Flink for years already. Even when merging forks of Flink that
>> transitively forked Calcite, in the end we were able to resolve
>> conflicts / contribute blockers back into Calcite. And I strongly
>> believe that this is the 

[jira] [Created] (CALCITE-5197) Bump gradle to 7.4.2 and add checksum autoupdate

[Sergey Nuyanzin (Jira)]

Sergey Nuyanzin created CALCITE-5197:


 Summary: Bump gradle to 7.4.2 and add checksum autoupdate
 Key: CALCITE-5197
 URL: https://issues.apache.org/jira/browse/CALCITE-5197
 Project: Calcite
  Issue Type: Improvement
  Components: build
Affects Versions: 1.30.0
Reporter: Sergey Nuyanzin


The problem with gradle update via
{code}
./gradlew wrapper --gradle-version  && ./gradlew autostyleApply
{code}
it removes checksum from {{gradle/wrapper/gradle-wrapper.properties}}

there could be added a task which could update checksum as well, e.g.
{code:kotlin}
tasks.wrapper {
distributionType = Wrapper.DistributionType.BIN
doLast {
val sha256Uri = URI("$distributionUrl.sha256")
val sha256Sum = String(sha256Uri.toURL().readBytes())
propertiesFile.appendText("distributionSha256Sum=${sha256Sum}\n")
}
}
{code}



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Created] (CALCITE-5196) Bump apiguardian version to 1.1.2 (latest)

[Sergey Nuyanzin (Jira)]

Sergey Nuyanzin created CALCITE-5196:


 Summary: Bump apiguardian version to 1.1.2 (latest)
 Key: CALCITE-5196
 URL: https://issues.apache.org/jira/browse/CALCITE-5196
 Project: Calcite
  Issue Type: Improvement
Affects Versions: 1.30.0
Reporter: Sergey Nuyanzin
Assignee: Sergey Nuyanzin






--
This message was sent by Atlassian Jira
(v8.20.7#820007)

Re: PR Review Request

[Ruben Q L]

+1 on Stamatis' idea, I think it could help with the current situation of
lack of reviewers.

Best,
Ruben


On Thu, Jun 23, 2022 at 12:56 PM Charles Givre  wrote:

> Hello all,
> FWIW, If a committer/reviewer shortage is the issue, I'd second Stamatis's
> recommendation.
> Best,
> -- C
>
> > On Jun 23, 2022, at 7:02 AM, Stamatis Zampetakis 
> wrote:
> >
> > Hi all,
> >
> > How about granting Calcite committership to people who are already ASF
> > committers (in other projects) and they have a proven record of working
> > with Calcite?
> >
> > Usually the PMC invites people to become committers to the project after
> > having a few successful code contributions in Calcite/Avatica repos.
> > This is to ensure that people are familiar with the codebase and
> understand
> > how the ASF works.
> >
> > People who are already committers in an ASF project already know how the
> > foundation works and how they should behave.
> > Also people working in projects like Drill, Flink, Hive, Ignite, Phoenix,
> > etc., may already be quite familiar with Calcite if they have worked on
> the
> > query processing layer of the system.
> >
> > It might be difficult for the Calcite PMC to identify people familiar
> with
> > Calcite if they don't contribute to the main Calcite/Avatica repos
> > regularly thus I would be open to consider people for committers on a per
> > request basis.
> >
> > Example:
> > Bob is an ASF committer in Flink and he has pushed various contributions
> > around Calcite in the Flink repo.
> > Bob feels confident about fixing trivial things in Calcite and he wants
> to
> > help with reviewing and merging open PRs.
> > Bob sends an email to private@calcite list requesting to become a
> Calcite
> > committer.
> > Bob explains in the email who he is and what he has done to demonstrate
> he
> > is familiar with the Calcite code.
> > The Calcite PMC acknowledges the request and starts a vote for granting
> > Calcite comittership to Bob.
> > The Calcite PMC informs Bob about their decision and takes further
> actions
> > if necessary.
> >
> > If we agree on the overall idea we can figure out the details and
> formalize
> > the request process in our docs.
> >
> > Best,
> > Stamatis
> >
> > On Thu, Jun 23, 2022 at 6:06 AM Jing Zhang  wrote:
> >
> >> Hi everyone,
> >>
> >> This is an awesome discussion to improve collaborating between different
> >> projects.
> >> Thanks Julian, Jacques, Austin, Martijn, Timo's effort to make it
> happen.
> >>
> >> Best,
> >> Jing Zhang
> >>
> >> Martijn Visser  于2022年6月23日周四 01:43写道：
> >>
> >>> Hi Jacques, Julian, Austin and everyone else,
> >>>
> >>> Thank you very much for sharing all your experiences and providing
> really
> >>> valuable input. I'll definitely relay this back to the original
> >> discussion
> >>> thread in the Flink community. Part of bringing this information back
> to
> >>> the Flink community is also because I feel like the only way that
> >> different
> >>> OSS solutions can help each other forward is by communicating and
> >>> collaborating. As Timo already mentioned, he'll try to help out. Let's
> >> try
> >>> to get some more involved.
> >>>
> >>> Side note: I also saw that this thread got some traction on Twitter [1]
> >> on
> >>> the cost of forking.
> >>>
> >>> Best regards,
> >>>
> >>> Martijn
> >>>
> >>> [1]
> >>>
> >>>
> >>
> https://twitter.com/gunnarmorling/status/1539499415337111553?s=21=8fGk3PxScOx4FJPJWE5UeA
> >>>
> >>> Op wo 22 jun. 2022 om 09:29 schreef Timo Walther :
> >>>
>  Hi everyone,
> 
>  This is a really great discussion. Thanks for starting it Martijn and
>  your input Jacques! I have been fighting against forking Calcite in
>  Flink for years already. Even when merging forks of Flink that
>  transitively forked Calcite, in the end we were able to resolve
>  conflicts / contribute blockers back into Calcite. And I strongly
>  believe that this is the better approach for long-term success for
> both
>  projects.
> 
>  I would like to get more involved in the Calcite community. I have
> been
>  implementing and managing Flink SQL based on Calcite since 2016. Thus,
> >> I
>  feel confident to say that I know the code base and some quirks in the
>  stack very well.
> 
>  Capacity-wise I will try to reserve some time for helping the Calcite
>  community. Happy to get some pointers where and how I can help.
> 
>  I will take a look at https://github.com/apache/calcite/pull/2606
> this
>  week to get the ball rolling. As this is an important addition and
>  prepares for "customer SQL operators" in Flink SQL.
> 
>  Regards,
>  Timo
> 
>  On 21.06.22 22:18, Charles Givre wrote:
> > As the PMC for Apache Drill, I'd echo everyone's comments here
> >>> Don't
>  fork.   Don't do it.
> >
> > Apache Drill forked Calcite several years ago which Calcite was on
>  version 1.20 or 1.21.  While this meant that some bugs 

Re: Aggregates push down

[Benchao Li]

Вадим,

Yes, we are short of documentation at the moment.

There is source code for adapters with processing aggregates, for example,
> Mongodb,

This is another different topic, adaptors such as Mongo/JDBC, they
transformed all
the RelNodes to their own convention, and then translate the RelNodes to
their own
query dialect. They do not pushdown filter/projection/aggregate, but they
invent a
method to implement the whole RelNode tree.

Вадим Ахмедов  于2022年6月22日周三 15:09写道：

> Hi Benchao,
> Thank you very much for your reply. Unfortunately, I did not find what you
> wrote in the Calcite documentation. It seems to be very sketchy. There is
> source code for adapters with processing aggregates, for example, Mongodb,
> but to understand thoroughly this it needs to spend a lot of time, which is
> often not enough. If there were examples in documentation explaining the
> minimum implementation of pushdown projections, the minimum implementation
> of pushdown filters, and the same for aggregates, it would be very helpful.
>
> сб, 18 июн. 2022 г. в 11:50, Benchao Li :
>
> > Hi Вадим,
> >
> > I'd like to share how the projections and filters are pushed down
> > in the first place.
> >
> > 1. Firstly we should have a RelNode which can do projections and
> > filters, and in Calcite, this is done by BindableTableScan[1].
> > 2. Then we need a rule to match such as Filter/Project on top of Scan,
> > and push the filters into the Scan, and in Calcite this is done
> > by FilterTableScanRule[2] and ProjectTableScanRule[3].
> > 3. Finally, we should translate the Scan with filters and/or projections
> > to a executable form, this may be different for different projections
> > because they have their own physical representations. In Calcite,
> > BindableTableScan will be transformed to TableScanNode[4], which
> > will further push filters and projections into
> > ProjectableFilterableTable[5].
> >
> > Hence, to extend Calcite to push aggregations into Scan, you need
> > the same process. You need a physical Scan node which can do
> aggregations,
> > and a rule to match Aggregate on top of Scan to push it down. Then you
> also
> > need to implement the corresponding physical logics.
> >
> > If you want the Scan node to do all the projection/filter/aggregation
> > pushdown,
> > you need to be careful to deal with the mix of them, because generally
> they
> > are not pushed down in one go, e.g. you may push a aggregation into a
> Scan
> > which has been pushed the filters down.
> >
> > Hope this helps~
> >
> > [1]
> >
> >
> https://github.com/apache/calcite/blob/de41df4d117041fbee042e07f70e6043f1fe626d/core/src/main/java/org/apache/calcite/interpreter/Bindables.java#L207
> > [2]
> >
> >
> https://github.com/apache/calcite/blob/de41df4d117041fbee042e07f70e6043f1fe626d/core/src/main/java/org/apache/calcite/rel/rules/FilterTableScanRule.java#L57
> > [3]
> >
> >
> https://github.com/apache/calcite/blob/de41df4d117041fbee042e07f70e6043f1fe626d/core/src/main/java/org/apache/calcite/rel/rules/ProjectTableScanRule.java#L57
> > [4]
> >
> >
> https://github.com/apache/calcite/blob/de41df4d117041fbee042e07f70e6043f1fe626d/core/src/main/java/org/apache/calcite/interpreter/TableScanNode.java#L63
> > [5]
> >
> >
> https://github.com/apache/calcite/blob/de41df4d117041fbee042e07f70e6043f1fe626d/core/src/main/java/org/apache/calcite/schema/ProjectableFilterableTable.java#L38
> >
> > Вадим Ахмедов  于2022年6月17日周五 16:59写道：
> >
> > > Hi!
> > >
> > > I'm modifying a driver based on Apache Calcite that works with AWS S3
> > > storage using SQL queries. The interaction with S3 storage uses the S3
> > > Select dialect which is very similar to SQL. The driver uses
> > > ProjectableFilterableTable to scan CSV data loaded from AWS. The
> filters
> > as
> > > a list of RexNodes are used in the scan method to transform SQL queries
> > > into AWS S3 Select queries. Thus push down of projects and filters is
> > done
> > > into requests to the S3 storage.
> > >
> > > Now I need to modify the driver in such a way that the push down of
> > > aggregate functions additionally occurs.
> > >
> > > Calcite documentation has a hint:
> > > "If you want more control, you should write a planner rule. This will
> > allow
> > > you to push down expressions, to make a cost-based decision about
> whether
> > > to push down processing, and push down more complex operations such as
> > > join, aggregation, and sort."
> > >
> > > I really need advice on how I can push down the aggregate functions
> with
> > > minimal modification of the driver source code. I have to ignore the
> > > aggregate functions in SQL somehow and push them into queries in S3
> > Select
> > > so that the aggregation occurs on the S3 side and not in memory.
> > >
> > > If I try to replace ProjectableFilterableTable with TranslatableTable
> the
> > > code will become 10 times more complicated.
> > >
> > > Maybe there is some simpler way to push down the aggregates?
> > >
> > > If TranslatableTable is the 

Re: PR Review Request

[Charles Givre]

Hello all, 
FWIW, If a committer/reviewer shortage is the issue, I'd second Stamatis's 
recommendation.
Best,
-- C

> On Jun 23, 2022, at 7:02 AM, Stamatis Zampetakis  wrote:
> 
> Hi all,
> 
> How about granting Calcite committership to people who are already ASF
> committers (in other projects) and they have a proven record of working
> with Calcite?
> 
> Usually the PMC invites people to become committers to the project after
> having a few successful code contributions in Calcite/Avatica repos.
> This is to ensure that people are familiar with the codebase and understand
> how the ASF works.
> 
> People who are already committers in an ASF project already know how the
> foundation works and how they should behave.
> Also people working in projects like Drill, Flink, Hive, Ignite, Phoenix,
> etc., may already be quite familiar with Calcite if they have worked on the
> query processing layer of the system.
> 
> It might be difficult for the Calcite PMC to identify people familiar with
> Calcite if they don't contribute to the main Calcite/Avatica repos
> regularly thus I would be open to consider people for committers on a per
> request basis.
> 
> Example:
> Bob is an ASF committer in Flink and he has pushed various contributions
> around Calcite in the Flink repo.
> Bob feels confident about fixing trivial things in Calcite and he wants to
> help with reviewing and merging open PRs.
> Bob sends an email to private@calcite list requesting to become a Calcite
> committer.
> Bob explains in the email who he is and what he has done to demonstrate he
> is familiar with the Calcite code.
> The Calcite PMC acknowledges the request and starts a vote for granting
> Calcite comittership to Bob.
> The Calcite PMC informs Bob about their decision and takes further actions
> if necessary.
> 
> If we agree on the overall idea we can figure out the details and formalize
> the request process in our docs.
> 
> Best,
> Stamatis
> 
> On Thu, Jun 23, 2022 at 6:06 AM Jing Zhang  wrote:
> 
>> Hi everyone,
>> 
>> This is an awesome discussion to improve collaborating between different
>> projects.
>> Thanks Julian, Jacques, Austin, Martijn, Timo's effort to make it happen.
>> 
>> Best,
>> Jing Zhang
>> 
>> Martijn Visser  于2022年6月23日周四 01:43写道：
>> 
>>> Hi Jacques, Julian, Austin and everyone else,
>>> 
>>> Thank you very much for sharing all your experiences and providing really
>>> valuable input. I'll definitely relay this back to the original
>> discussion
>>> thread in the Flink community. Part of bringing this information back to
>>> the Flink community is also because I feel like the only way that
>> different
>>> OSS solutions can help each other forward is by communicating and
>>> collaborating. As Timo already mentioned, he'll try to help out. Let's
>> try
>>> to get some more involved.
>>> 
>>> Side note: I also saw that this thread got some traction on Twitter [1]
>> on
>>> the cost of forking.
>>> 
>>> Best regards,
>>> 
>>> Martijn
>>> 
>>> [1]
>>> 
>>> 
>> https://twitter.com/gunnarmorling/status/1539499415337111553?s=21=8fGk3PxScOx4FJPJWE5UeA
>>> 
>>> Op wo 22 jun. 2022 om 09:29 schreef Timo Walther :
>>> 
 Hi everyone,
 
 This is a really great discussion. Thanks for starting it Martijn and
 your input Jacques! I have been fighting against forking Calcite in
 Flink for years already. Even when merging forks of Flink that
 transitively forked Calcite, in the end we were able to resolve
 conflicts / contribute blockers back into Calcite. And I strongly
 believe that this is the better approach for long-term success for both
 projects.
 
 I would like to get more involved in the Calcite community. I have been
 implementing and managing Flink SQL based on Calcite since 2016. Thus,
>> I
 feel confident to say that I know the code base and some quirks in the
 stack very well.
 
 Capacity-wise I will try to reserve some time for helping the Calcite
 community. Happy to get some pointers where and how I can help.
 
 I will take a look at https://github.com/apache/calcite/pull/2606 this
 week to get the ball rolling. As this is an important addition and
 prepares for "customer SQL operators" in Flink SQL.
 
 Regards,
 Timo
 
 On 21.06.22 22:18, Charles Givre wrote:
> As the PMC for Apache Drill, I'd echo everyone's comments here
>>> Don't
 fork.   Don't do it.
> 
> Apache Drill forked Calcite several years ago which Calcite was on
 version 1.20 or 1.21.  While this meant that some bugs were easily
>> fixed,
 what it also meant that as our fork diverged from "regular" Calcite, it
 became harder and harder to maintain.  It also meant that we were
>> chasing
 bugs that had since been fixed.
> 
> Drill is in the process of "de-forking" Calcite, meaning that we're
 ditching our fork and re-integrating with standard Calcite.  It has
>> been
>>> A
 TON of work and we 

Re: PR Review Request

[Stamatis Zampetakis]

Hi all,

How about granting Calcite committership to people who are already ASF
committers (in other projects) and they have a proven record of working
with Calcite?

Usually the PMC invites people to become committers to the project after
having a few successful code contributions in Calcite/Avatica repos.
This is to ensure that people are familiar with the codebase and understand
how the ASF works.

People who are already committers in an ASF project already know how the
foundation works and how they should behave.
Also people working in projects like Drill, Flink, Hive, Ignite, Phoenix,
etc., may already be quite familiar with Calcite if they have worked on the
query processing layer of the system.

It might be difficult for the Calcite PMC to identify people familiar with
Calcite if they don't contribute to the main Calcite/Avatica repos
regularly thus I would be open to consider people for committers on a per
request basis.

Example:
Bob is an ASF committer in Flink and he has pushed various contributions
around Calcite in the Flink repo.
Bob feels confident about fixing trivial things in Calcite and he wants to
help with reviewing and merging open PRs.
Bob sends an email to private@calcite list requesting to become a Calcite
committer.
Bob explains in the email who he is and what he has done to demonstrate he
is familiar with the Calcite code.
The Calcite PMC acknowledges the request and starts a vote for granting
Calcite comittership to Bob.
The Calcite PMC informs Bob about their decision and takes further actions
if necessary.

If we agree on the overall idea we can figure out the details and formalize
the request process in our docs.

Best,
Stamatis

On Thu, Jun 23, 2022 at 6:06 AM Jing Zhang  wrote:

> Hi everyone,
>
> This is an awesome discussion to improve collaborating between different
> projects.
> Thanks Julian, Jacques, Austin, Martijn, Timo's effort to make it happen.
>
> Best,
> Jing Zhang
>
> Martijn Visser  于2022年6月23日周四 01:43写道：
>
> > Hi Jacques, Julian, Austin and everyone else,
> >
> > Thank you very much for sharing all your experiences and providing really
> > valuable input. I'll definitely relay this back to the original
> discussion
> > thread in the Flink community. Part of bringing this information back to
> > the Flink community is also because I feel like the only way that
> different
> > OSS solutions can help each other forward is by communicating and
> > collaborating. As Timo already mentioned, he'll try to help out. Let's
> try
> > to get some more involved.
> >
> > Side note: I also saw that this thread got some traction on Twitter [1]
> on
> > the cost of forking.
> >
> > Best regards,
> >
> > Martijn
> >
> > [1]
> >
> >
> https://twitter.com/gunnarmorling/status/1539499415337111553?s=21=8fGk3PxScOx4FJPJWE5UeA
> >
> > Op wo 22 jun. 2022 om 09:29 schreef Timo Walther :
> >
> > > Hi everyone,
> > >
> > > This is a really great discussion. Thanks for starting it Martijn and
> > > your input Jacques! I have been fighting against forking Calcite in
> > > Flink for years already. Even when merging forks of Flink that
> > > transitively forked Calcite, in the end we were able to resolve
> > > conflicts / contribute blockers back into Calcite. And I strongly
> > > believe that this is the better approach for long-term success for both
> > > projects.
> > >
> > > I would like to get more involved in the Calcite community. I have been
> > > implementing and managing Flink SQL based on Calcite since 2016. Thus,
> I
> > > feel confident to say that I know the code base and some quirks in the
> > > stack very well.
> > >
> > > Capacity-wise I will try to reserve some time for helping the Calcite
> > > community. Happy to get some pointers where and how I can help.
> > >
> > > I will take a look at https://github.com/apache/calcite/pull/2606 this
> > > week to get the ball rolling. As this is an important addition and
> > > prepares for "customer SQL operators" in Flink SQL.
> > >
> > > Regards,
> > > Timo
> > >
> > > On 21.06.22 22:18, Charles Givre wrote:
> > > > As the PMC for Apache Drill, I'd echo everyone's comments here
> > Don't
> > > fork.   Don't do it.
> > > >
> > > > Apache Drill forked Calcite several years ago which Calcite was on
> > > version 1.20 or 1.21.  While this meant that some bugs were easily
> fixed,
> > > what it also meant that as our fork diverged from "regular" Calcite, it
> > > became harder and harder to maintain.  It also meant that we were
> chasing
> > > bugs that had since been fixed.
> > > >
> > > > Drill is in the process of "de-forking" Calcite, meaning that we're
> > > ditching our fork and re-integrating with standard Calcite.  It has
> been
> > A
> > > TON of work and we have contributed (and will continue to contribute)
> bug
> > > fixes and PRs to Calcite. In the long run, I think this will be
> > beneficial
> > > for both communities.
> > > >
> > > > Best,
> > > > -- C
> > > >
> > > >
> > > >> On Jun 21, 2022, at 1:57 PM, Julian 

Re: CI Failed in JDK15

[Alessandro Solimando]

Hi Yanjing,
we have had an identical failure in March (logs are not available anymore,
unfortunately) in the snapshot build:
"Build failed in Jenkins: Calcite » Calcite-snapshots #88", related to the
commit "[fan_li_ya] [CALCITE-4976] Release Calcite 1.30.0"

> Task :server:test
>  [0;31;1mFAILURE [0m  [0;1m  5.6sec [0m, org.apache.calcite.test.
> [0;1mServerTest [0m >  [0;1mtestInsertCreateNewCompositeUdt() [0m
> java.sql.SQLException: Error while executing SQL "create type mytype
> as (i int, j int)": Method not found: execute([class
> org.apache.calcite.sql.SqlNode, interface
> org.apache.calcite.jdbc.CalcitePrepare$Context])
> at
> org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at
> org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:163)
> at
> org.apache.calcite.avatica.AvaticaStatement.execute(AvaticaStatement.java:217)
>  [0;1mat
> org.apache.calcite.test.ServerTest.testInsertCreateNewCompositeUdt(ServerTest.java:309)
>  [0mNext exception 1: [CIRCULAR REFERENCE SQLException]
> Next exception 2: java.lang.IllegalArgumentException: Method not
> found: execute([class org.apache.calcite.sql.SqlNode, interface
> org.apache.calcite.jdbc.CalcitePrepare$Context])
> at
> org.apache.calcite.util.ReflectUtil$2.lookupMethod(ReflectUtil.java:563)
> at
> org.apache.calcite.util.ReflectUtil$2.invoke(ReflectUtil.java:527)
> at
> org.apache.calcite.server.DdlExecutorImpl.executeDdl(DdlExecutorImpl.java:41)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.executeDdl(CalcitePrepareImpl.java:370)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:635)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:514)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:484)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:234)
> at
> org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:623)
> at
> org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:674)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:156)
>  [0;0;90m... 2 more
>  [0mCaused by: [CIRCULAR REFERENCE IllegalArgumentException]
>
>  [0;1m  5.8sec [0m, org.apache.calcite.test. [0;1mServerTest [0m
> >  [0;1mtestDropType() [0m
>  [0;1m  5.7sec [0m, org.apache.calcite.test. [0;1mServerTest [0m
> >  [0;1mtestCreateFunction() [0m
>  [0;1m  5.8sec [0m, org.apache.calcite.test. [0;1mServerTest [0m
> >  [0;1mtestDropFunction() [0m
>  [0;1m  5.8sec [0m, org.apache.calcite.test. [0;1mServerTest [0m
> >  [0;1mtestDropWithFullyQualifiedNameWhenSchemaDoesntExist() [0m
>  [0;1m  7.1sec [0m, org.apache.calcite.test. [0;1mServerTest [0m
> >  [0;1mtestStatement() [0m
>  [0;1m  7.4sec [0m, org.apache.calcite.test. [0;1mServerTest [0m
> >  [0;1mtestCreateSchema() [0m
>  [0;1m  7.5sec [0m, org.apache.calcite.test. [0;1mServerTest [0m
> >  [0;1mtestVirtualColumn() [0m
>  [0;1m  7.5sec [0m, org.apache.calcite.test. [0;1mServerTest [0m
> >  [0;1mtestVirtualColumnWithFunctions() [0m
>  [0;1m  7.5sec [0m, org.apache.calcite.test. [0;1mServerTest [0m
> >  [0;1mtestCreateType() [0m
>  [0;1m  7.9sec [0m, org.apache.calcite.test. [0;1mServerTest [0m
> >  [0;1mtestCreateTable() [0m
>  [0;1m  6.0sec [0m, org.apache.calcite.test. [0;1mServerQuidemTest
> [0m >  [0;1mtest(String) [0m[3], [3] sql/type.iq
>  [0;1m  9.3sec [0m, org.apache.calcite.test. [0;1mServerTest [0m
> >  [0;1mtestInsertCastedValueOfCompositeUdt() [0m
>  [0;1m  7.4sec [0m, org.apache.calcite.test. [0;1mServerQuidemTest
> [0m >  [0;1mtest(String) [0m[4], [4] sql/view.iq
>  [0;1m  7.6sec [0m, org.apache.calcite.test. [0;1mServerQuidemTest
> [0m >  [0;1mtest(String) [0m[2], [2] sql/table.iq
>  [0;1m  9.9sec [0m, org.apache.calcite.test. [0;1mServerTest [0m
> >  [0;1mtestStoredGeneratedColumn() [0m
>  [0;31;1mFAILURE [0m  10.4sec,   15 completed,  [0;31;1m  1 [0m failed,
> [0;34;1m  1 [0m skipped, org.apache.calcite.test. [0;31;1mServerTest [0m
>  [0;1m  7.9sec [0m, org.apache.calcite.test. [0;1mServerQuidemTest
> [0m >  [0;1mtest(String) [0m[5], [5] sql/table_as.iq
>

So I don't think it's a regression on your patch, can you re-trigger your
tests to check if it's transient or not?

In any case, can you please file a Jira for this?

Best regards,
Alessandro

On Thu, 23 Jun 2022 at 05:09, Yanjing Wang 
wrote:

> Hi, I encountered the following failure in JDK15, but the other JDK
> versions are ok.
>
>