Vladimir Sitnikov created CALCITE-6112:
--
Summary: Use inedible release tags
Key: CALCITE-6112
URL: https://issues.apache.org/jira/browse/CALCITE-6112
Project: Calcite
Issue Type
Vladimir Sitnikov created CALCITE-6019:
--
Summary: Excessive cast when UDF receives nullable JavaType
Key: CALCITE-6019
URL: https://issues.apache.org/jira/browse/CALCITE-6019
Project: Calcite
Vladimir Sitnikov created CALCITE-6018:
--
Summary: Support nullable parameters in UDFs
Key: CALCITE-6018
URL: https://issues.apache.org/jira/browse/CALCITE-6018
Project: Calcite
Issue
Vladimir Sitnikov created CALCITE-6012:
--
Summary: CAST($t4):JavaType(class java.lang.Object) NOT NULL
causes NPE since 1.27
Key: CALCITE-6012
URL: https://issues.apache.org/jira/browse/CALCITE-6012
Vladimir Sitnikov created CALCITE-6010:
--
Summary: RelRule.Config requires too much ceremony for trivial
cases
Key: CALCITE-6010
URL: https://issues.apache.org/jira/browse/CALCITE-6010
Project
Vladimir Sitnikov created CALCITE-5034:
--
Summary: Disable Gradle build cache or use an alternative accout
for it
Key: CALCITE-5034
URL: https://issues.apache.org/jira/browse/CALCITE-5034
Project
ide, so it makes many
checkstyle verifications obsolete == much less failures like "you missed a
space after comma".
Recently I suggested "migrating to GitHub Issues".
https://lists.apache.org/thread/m2h13v2p7kowglj73qr4sqn1c3pm8tlq
Technically speaking, the results in th
Gavin,
Please check sample schemata in
https://github.com/apache/calcite/tree/7a7b37fc1f4bd2121643539b0fd8e9c4f0f8ed09/testkit/src/main/java/org/apache/calcite/test/schemata
If you find useful schemas, don't hesitate filing a PR to add samples to
/testkit/
Vladimir
>I'm afraid this is not accurate.
Nothing is accurate, so what do you suggest?
Vladimir
>This is an accurate label ? I just want to confirm.
Please rephrase. I don't understand it.
Vladimir
>This will request to add another Label to every PR
Release drafter can automatically add labels based on the filenames.
PRs without labels are still acceptable, so having labels is not a
requirement.
Vladimir
Hi,
I suggest we start using Release Drafter [1] for the preparation of the
release notes.
I'm going to submit and merge a PR soon, however, I would appreciate it if
somebody else
would do that (see [2] for a minimal commit)
I am sure it would significantly increase the quality of the release
Julian,
Please refrain from insisting that others should follow the
manual procedures you create.
If you want to have certain manual steps for your own safety, that is fine.
However, don't expect the others will be following all the manual steps you
invent.
I suggest we gather a meetup to
>For Gradle upgrades, there’s only one place to modify.
Juilan,
Are you willing to keep the place updated?
If so, there's no need to raise mail threads, please just update it.
Vladimir
Julian, I know it might be tough, yet:
1) I would like you to believe me I just forgot howto and the other places
hard-code Java versions.
Of course, "we support Java 17" is a notable change, and it does deserve to
be in the release notes,
however, the typical current process is to "file JIRA for
There are issues, and it does fail quite often. It is really frustrating.
I can disable the test if you think it would be better.
Based on past experience, we almost never revisit disabled tests, and it
would look as if "server" passes tests, however, it corrupts data.
Vladimir
>First some annoying :core:checkstyleTest that interferes with files
generated by Intellij IDEA, with hundreds of error messages similar to the
following:
We exclude generated files from the style checks via the following patterns:
The failure is known as https://issues.apache.org/jira/browse/CALCITE-4824
Does anybody use calcite-server?
Does anybody have cycles to maintain/fix calcite-server?
Can we just remove it?
Vladimir
Julian>We don’t need any more noise on the dev list.
Julian at all, please consider ASF Jenkins failures as true failures rather
than "infrastructure noise".
The messages could probably be improved, however, I have not explored them.
Jenkins won't send mails in case everything is ok.
Jacques>if
>some direct or indirect changes (metadata, rules, validator, etc)
>may cause changes to plans around the given RelNode in the downstream
>project
Do you think changes like "metadata, rules, validator" can cause "wrong
results" issues?
What could be the issues caused by "metadata, rules,
>practice I fear that
>it will introduce a lot of red tape and false negatives
I am afraid "wrong results and corrupted data in database" is way worse
than "recompiling in case of Calcite update".
>I don't recall
>any feedback (positive or otherwise) about how we describe breaking
>changes
>Where is -Pasf defined/documented?
https://calcite.apache.org/docs/howto.html#making-a-snapshot
Vladimir
Hi,
It turns out Calcite's nodes can change semantics without notification for
the end-users.
Here are the release notes for Calcite 1.21, and it says **nothing** like
"Ensure you handle Filter#variablesSet in case you implement Filter or in
case you transform LogicalFilter in your rules"
Jacques, which credentials are you going to supply to publish the snapshots
to the ASF repository from GitHub?
While I agree with moving towards GitHub actions, I would like to minimize
the use of ASF credentials in non-ASF environments.
Luckily, ASF infra supplies the relevant credentials for
I wonder if we can add GitHub action that would react to committers comment
/squash by squashing the commits and pushing --force-with-lease to the fork
branch.
If pushing to the fork is not possible in GHA, then something like /merge
that squashes, rebases and pushes to apache/calcite would be
Moving the reply to DISCUSS thread.
Ruben>My vote might be biased because I have used Jira for many years (and
I have
Ruben>never used Github for issue tracking).
It is really sad to hear.
You authored 87 PRs for Calcite!
You did use GitHub for tracking already.
>I think JIRA works well.
I would appreciate it if you could clarify.
What I suggest would work better than JIRA in virtually all the cases. So
why stick with JIRA?
Vladimir
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
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
>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
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
>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
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
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
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
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:
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,
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
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/
>A bigger problem around our process that I see is not enough reviews/triage
for the contributions we do receive. We have 224 open prs and I'd estimate
a median open time of 1 year+
I am sure JIRA is slowing us down here.
If we accept we do not need JIRA, PRs could become the way to go for the
Stamatis>Quite interesting information so far
One more data point: LLVM is migrating issues from their Bugzilla to GitHub
Issues right now (52K issues!)
See https://llvm.discourse.group/t/bugzilla-migration/4848
Vladimir
>I know people/companies who have built tools/plugins
>around JIRA for getting useful information such as which internal forks
>have this particular fix, etc
That is true. However, I do not know what should we do about it.
Of course, any change brings hidden costs, so if the benefits are unclear,
>I think the easiest thing is to focus on the
>"workflow" for each "persona" we have
While I agree the questions you raise are valid, I would say, that moving
to GitHub Issues
does not really change the workflow except in certain small cases.
I doubt there's an exhaustive list of answers for
>since core/src/kotlin does not exist yet.
I mean core/src/main/kotlin does not exist yet
Vladimir
If it is a transitive dependency, then it is a transitive dependency.
Otherwise it is a bug.
I'm sure calcite-core itself does not use kotlin stdlib since
core/src/kotlin does not exist yet.
Vladimir
>All that said, this was a number of years ago
I agree. GitHub makes noticeable progress nowadays.
>I'd want to see that demonstrated before
>changing all of Calcite over.
How do you want that demonstrated?
Apache Airflow does use GitHub Issues, they do ship releases.
Many top-starred Apache
>I haven't found navigating JIRA + GitHub PRs to be a significant
>problem, but if others think it would help
GitHub has a single search field, so you can search for both PRs and issues
at the same time which is nice as well.
>will my GH comments end up as coming from @michaelmior
If we migrate
Here's Airflow vote thread (~2020):
https://lists.apache.org/thread/s5nk0mgblkzq9jrqgrvp12yn4kmy0o7b
here's the discussion:
https://lists.apache.org/thread/6lfth3o4gzk3s891bcqy045z5gl4fs07
I believe draft PRs could avoid "DISCUS" threads that suck time from
everybody and those DISCUSS threads add
>Mark the fix versions of each JIRA issue. It is visible for users to
>find which version contain this functionality or fix this bug.
GitHub has "milestones".
See how it is used in Airflow:
https://github.com/apache/airflow/milestone/45?closed=1
>2. Watch the interested issue so I could receive
We can copy all the issues, including resolved ones.
We can import issues. GitHub has api for importing without notifications.
Infra team can execute such a script (we need to find it)
Vladimir
Hi,
What do you think of moving to GitHub Issues for Calcite?
Currently, my (Calcite) development workflow focuses on pull requests.
That is all contributions I see come via pull requests.
At the same time, issues are hosted in JIRA, which creates friction: PR
merging requires changes to both
>Are the people willing to give a talk around Calcite?
I may present a talk regarding Gradle, and the upcoming migration to the
idiomatic structure:
https://issues.apache.org/jira/browse/CALCITE-4832
https://github.com/apache/calcite/pull/2566
Jacques>Based on this, I would suggest we do a small
Jacques>modification around CI on Calcite whereby pre-commit tests do not
include
Jacques>running against Avatica main and instead we have a post-merge CI
job that
Jacques>monitors the status of connecting the two
Suppose PR verification
Jacques>This sounds like it will mean we will need to make calcite-core
test artifacts available
Test artifacts publication is yet another anti-pattern just like "base test
class".
This change has been discussed:
https://lists.apache.org/thread/fz96p94h016p11g777otqntjxg2oxgh1
If you want to
Julian,
Thanks for taking time, and working on this.
"Fixture" is a too broad term, and I do not mean we should replace it
completely with AssertJ.
What I mean is that AssertJ allows creating *discoverable* assertions.
Hamcrest assertions are hard to create and hard to discover in IDE.
---
Re
Vladimir Sitnikov created CALCITE-4889:
--
Summary: Double join is created for NOT IN
Key: CALCITE-4889
URL: https://issues.apache.org/jira/browse/CALCITE-4889
Project: Calcite
Issue Type
Josh>I am still upset from the porting of Avatica to Gradle
Please migrate Avatica to whatever build system you like.
I disagree with you a lot, however, I stop commenting as I do not see it
might change your mind.
I'm not touching Avatica anymore.
me>I am going to delete/ignore the offending
s/John/Josh/
sorry for the typo.
Vladimir
Josh>because I genuinely do not see how this approach
Josh>creates more code that needs to be written than if the projects were in
Josh>the same repository.
Compare
https://github.com/apache/calcite-avatica/blob/4cf769f8ee32bb3520604e4f3284e6f233f90276/build.gradle.kts
and
Josh>I have no objections to combining these two repositories together.
Why don't we just merge the repositories and move on then?
Josh>If we identify these problems, we can think
Josh>through (from the beginning) if combining repositories is the only
Josh>solution or just one possible solution
Ok, I did not care when Avatica was split into its own repository, and I
assumed Avatica team would maintain the code.
That turned out to be not quite true, and it turns out there are
non-trivial overheads coming from the split.
Of course, everybody can disagree, so if you disagree, you don't
Michael> is not proposing to change the
Michael>structure of modules within both projects, merely to have the code
for
Michael>both in a single repository.
I propose to integrate them into a single build, and keep the set of the
published jars.
However, the modules and dependency structure could
Francis>I remembered joining this list a few years back then
Francis>- Calcite - SQL engine used to build the SQL part of your database.
The things is "apache/calcite" is tons of features as in "thing that
converts SQL to MongoDB" or "thing that executes SQL queries over InnoDB
data files",
or
I know the below is too wordy, however, English is not my native language,
so I tend to overexplain and duplicate thoughts.
Julian>To allow separate communities
This is something I do not understand.
Let me be explicit: I am OK to maintain bits of avatica code when Calcite
fixes overlap with
Vladimir Sitnikov created CALCITE-4881:
--
Summary: Calcite release tags should have rel/... prefix as per
the ASF requirements
Key: CALCITE-4881
URL: https://issues.apache.org/jira/browse/CALCITE-4881
Currently CI for avatica verifies building with calcite/master, and vice
versa.
Otherwise we won't notice integration issues before we release.
Julian suggested that we should support one avatica version only. I agree,
especially of that means we merge the repositories back.
> I think it is a
Hi,
Currently, we have calcite-avatica and calcite in different repositories.
Frankly speaking, I do not know what it brings, however, it does create
points of friction:
1) If a feature touches Avatica and Calcite, then PRs are hard to create
and maintain. We just can't create a single PR across
I was able to reproduce the same release artifact
(d61c4935d7d3b664..) locally, so +1 for releasing it.
Steps for macOS:
git worktree add ../calcite-1.28.0 dec167ac18272c0cd8be477d6b162d7a31a62114
cd ../calcite-1.28.0
JAVA_HOME=$(/usr/libexec/java_home -v 1.8) ./gradlew distTar -Prelease
openssl
>Does no other build it locally for such a time ?:)
Evgeny, it is very likely you hit the bug because you use a stale version
of OpenJDK.
What Stamatis merged is not a fix, but it is a workaround.
In any case, if you use an outdated Java version, it is up to you to figure
out why the build does
Vladimir Sitnikov created CALCITE-4832:
--
Summary: Refactor Gradle to build-logic convention plugins
Key: CALCITE-4832
URL: https://issues.apache.org/jira/browse/CALCITE-4832
Project: Calcite
What is the exact Java version you are using?
It looks like https://bugs.openjdk.java.net/browse/JDK-8032211 , and it
might be that newer OpenJDK include the fix.
Vladimir
Vladimir Sitnikov created CALCITE-4829:
--
Summary: Bump Gradle to 7.2 and test with Java 17 at GitHub Actions
Key: CALCITE-4829
URL: https://issues.apache.org/jira/browse/CALCITE-4829
Project
I'm not sure which steps are you following, however, the same sequence
seems to work fine:
Commands:
https://github.com/vlsi/vlsi-release-plugins/blob/83c85c5faa4c7cd1fe0173b75c1cba5e60c3f209/.github/workflows/release-test.yml#L33-L60
Logs:
Vladimir Sitnikov created CALCITE-4824:
--
Summary: ServerUnParserTest#testCreateTableVirtualColumn fails
Key: CALCITE-4824
URL: https://issues.apache.org/jira/browse/CALCITE-4824
Project: Calcite
As suggested above, I've prepared a PR that moves CalciteAssert, Matchers,
and a couple of test schemata to the new :testkit module.
calcite-*-tests.jar will no longer be published.
PR: https://github.com/apache/calcite/pull/2558
The tests pass, and the change unlocks migration to Gradle 7.2
Vladimir Sitnikov created CALCITE-4823:
--
Summary: JEP 411: AccessControlException, AccessController in
java.security has been deprecated and marked for removal
Key: CALCITE-4823
URL: https
Vladimir Sitnikov created CALCITE-4821:
--
Summary: Move utility test classes into calcite-testkit and
unpublish -test.jar
Key: CALCITE-4821
URL: https://issues.apache.org/jira/browse/CALCITE-4821
>I don’t think we should do randomized CI
Then please incorporate:
a) Testing with "-XX:+UnlockExperimentalVMOptions -XX:hashCode=2" to ensure
the code does not rely on Object#hashCode uniqueness
b) different OSes
c) Different JDK vendors, versions and JIT implementations (e.g. OpenJ9,
Microsoft,
Here's a randomized matrix for Avatica:
https://github.com/apache/calcite-avatica/pull/156
https://github.com/apache/calcite-avatica/actions/runs/1298777387
Vladimir
I suggest to settle on the number of CI jobs we can afford to keep the CI
duration sane, and we generate a random sample. The number of CI jobs might
be different for PR builds and for branch builds.
We have many different interesting timezones, many Guava versions, only 3
OS, many JDKs for each
>CI should be deterministic
That is an interesting view.
One of the approaches that I have not considered earlier is "seed matrix
randomization from PR index and the branch name".
That would make the set of jobs consistent for each execution of the same
PR.
However, based on my testng/testng
>Of course it would be fine to just change the timezone for one of more
>existing tests which are targeting different JVM versions
Alessandro, team, what do you think of
https://github.com/vlsi/github-actions-random-matrix ?
I'm kind of hesitant to introduce more and more /vlsi/ dependencies
Stamatis>I don't think someone is spending time going over the list of
contributors
I agree here. It should be automated in order to be workable.
The contributors link you suggest is nice.
Vladimir
I incline to "The following people contributed to this release"
For instance, I like the way Gradle release notes are written:
https://docs.gradle.org/7.2/release-notes.html
The trick is that the author name does not convey the URL, so either we use
just names or we keep a contributor database.
Vladimir Sitnikov created CALCITE-4715:
--
Summary: Create CITATION.cff for BibTex, APA citation UI in GitHub
Key: CALCITE-4715
URL: https://issues.apache.org/jira/browse/CALCITE-4715
Project
https://issues.apache.org/jira/browse/CALCITE-4701 seems relevant.
I do not know if "parser extension" build system plugins already exist,
however, I think it would be nice to have one in Calcite.
Vladimir
Vladimir Sitnikov created CALCITE-4701:
--
Summary: Implement and publish Gradle plugin for extending the
parser
Key: CALCITE-4701
URL: https://issues.apache.org/jira/browse/CALCITE-4701
Project
Vladimir Sitnikov created CALCITE-4679:
--
Summary: Search/sarg simplification leaves is not null(literal)
unsimplified
Key: CALCITE-4679
URL: https://issues.apache.org/jira/browse/CALCITE-4679
Vladimir Sitnikov created CALCITE-4678:
--
Summary: AssertionError: result mismatch when simplifying
case+search+isdistinctfrom+isnottrue
Key: CALCITE-4678
URL: https://issues.apache.org/jira/browse/CALCITE
Vladimir, welcome!
>consistent signal from the "field" - lack of documentation blocks
I wonder if logging "missing sections" would help.
The catch here is if you work with Calcite for some time the missing docs
become a blind spot.
For instance, once I heard that if one wants to add a test
Julian>I’m not a fan of dependency injection. But it requires mutable
fields.
On contrary, DI does not require mutable fields, and field injection is
considered an anti-pattern in production code.
For example, see
https://github.com/google/guice/wiki/Injections#constructor-injection
I do
Vladimir Sitnikov created CALCITE-4659:
--
Summary: Introduce AssertJ and gradually migrate to its usage
instead of Hamcrest
Key: CALCITE-4659
URL: https://issues.apache.org/jira/browse/CALCITE-4659
Vladimir Sitnikov created CALCITE-4658:
--
Summary: Introduce refaster for automatic reformat of the code
Key: CALCITE-4658
URL: https://issues.apache.org/jira/browse/CALCITE-4658
Project: Calcite
Vladimir Sitnikov created CALCITE-4657:
--
Summary: Replace cancel-workflow-runs with GitHub in-core
cancel-in-progress feature
Key: CALCITE-4657
URL: https://issues.apache.org/jira/browse/CALCITE-4657
Ruben,
The next time the case reproduces, please collect the core dump.
At least you would be able to analyze it later.
It might be a VM issue (e.g. failing compilation), or it might be a
concurrency issue (e.g. data race in the parser code),
or something completely different.
You might find
Stamatis, thanks for preparing the release.
My vote is
[x] -1 Do not release this package because...
1) apache-calcite-1.27.0-src.tar.gz contains compiled code,
and it is forbidden to release compiled code in source packages.
site/js/html5shiv.min.js
site/js/respond.min.js
2)
>VolcanoPlanner flattens the composite trait into
the default trait value in RelSet.add -> RelTraitSet.simplify
Vladimir, have you tried removing that RelTraitSet.simplify?
I remember I have run into that multiple times already, and I suggested
removing that "simplify".
For example,
gt;
> The tally is as follows.
>
> 3 binding +1s:
> Francis Chuang
> Julian Hyde
> Stamatis Zampetakis
>
> 1 binding -1:
> Vladimir Sitnikov
>
> 1 non-binding +1s:
> Alessandro Solimando
>
> Therefore, I am delighted to announce that the proposal to release
> A
Vladimir Sitnikov created CALCITE-4618:
--
Summary: Refine dependency declarations to better account for type
annotations
Key: CALCITE-4618
URL: https://issues.apache.org/jira/browse/CALCITE-4618
Vladimir Sitnikov created CALCITE-4612:
--
Summary: Fuzzer for RelBuilder
Key: CALCITE-4612
URL: https://issues.apache.org/jira/browse/CALCITE-4612
Project: Calcite
Issue Type: Test
1 - 100 of 780 matches
Mail list logo
