[DISCUSS] Adapter's performance is not that fast
Hi everyone. My name is Xiangwei Wei and I'm new here. I wrote an adapter for Apache IoTDB recently which is a database for time series data management to support use of Apache Calcite. However, when I finished it and tried to test its performance, I found the adapter's performance was not that fast. It took much time compared with the raw data query in the database backend. I thought maybe it was the problem of my adapter. So I did the same test on the Cassandra Adapter which is provided by Calcite source code. But it shew similar result. Executing a simple query using Cassandra Adapter takes about 1600ms - 1800ms on my PC. However, it costs only 5 ms to do the raw data query in the Cassandra database backend. Is this the general performance of adapters? Or I made something wrong? I did the test by writing a simple JDBC program to do query using standard sql. For Cassandra Adapter, I used the data proviced in "./cassandra/src/test/resources/twissandra.cql" and a simple sql statement provided in the CassandraAdapterTest which is "select * from \"userline\" where \"username\"='!PUBLIC!'". -- Best, Xiangwei Wei
Re: [VOTE] Release apache-calcite-1.22.0 (release candidate 2)
Danny I agree that a -1 is disheartening. Especially when given for mistaken reasons. Technically a -1 does not kill an RC. We just need 3 more +1 votes than -1 votes. I urge everyone to give detailed rationale for their vote. Even if you vote +1, describe what you checked. Julian > On Feb 26, 2020, at 03:14, Danny Chan wrote: > > Gives a -1 when you are sure that it is a bug, or the voting would be very > depressing, anyone can give a -1 for any reasons. > > Best, > Danny Chan > 在 2020年2月26日 +0800 PM3:04，Enrico Olivelli ，写道： >> Danny, >> I have created https://issues.apache.org/jira/browse/CALCITE-3826 >> for the problem about bind variables in UPDATE statements. >> >> I feel this it can be a serious regression that can lead to data >> corruption (wrong data type in DML statements). >> AFAICT There is no way to workaround the problem in the application, >> because Calcite produces a wrong model for the query. >> >> It seems to be a regression introduced in >> https://issues.apache.org/jira/browse/CALCITE-3672 but I am not sure. >> we should confirm the bug and fix it or demonstrate that the bug is not valid >> >> -1 (non binding) >> >> Enrico >> >>> Il giorno mer 26 feb 2020 alle ore 07:34 Feng Zhu >>> ha scritto: >>> >>> Hi Danny, >>> Thanks for your efforts. >>> >>> +1 (non-binding) >>> >>> Environment: Windows 7, JDK 1.8.0_121 >>> - Build and Test (./gradlew build) - OK >>> - Checked Release Notes - OK >>> - Checked README - OK >>> >>> Best, >>> Feng >>> >>> Danny Chan 于2020年2月26日周三 下午1:23写道： >>> Hi all, I have created a build for Apache Calcite 1.22.0, release candidate 2. Thanks to everyone who has contributed to this release. You can read the release notes here: https://github.com/apache/calcite/blob/calcite-1.22.0/site/_docs/history.md The commit to be voted upon: https://gitbox.apache.org/repos/asf?p=calcite.git;a=commit;h=e397e47b0752c0647590097584903a9561a646eb Its hash is e397e47b0752c0647590097584903a9561a646eb. The artifacts to be voted on are located here: https://dist.apache.org/repos/dist/dev/calcite/apache-calcite-1.22.0-rc2/ The hashes of the artifacts are as follows: src.tar.gz.sha512 049a7650645106589b8fa65adf36ebbe90accf8359bcc05f40d7b50b00df9327b24b189c4cd1c0e12a702635cc1dc41f9e8b60238073bf83dfcff9c0ef60e66a *apache-calcite-1.22.0-src.tar.gz A staged Maven repository is available for review at: https://repository.apache.org/content/repositories/orgapachecalcite-1079 Release artifacts are signed with the following key: https://people.apache.org/keys/committer/danny0405.asc Please vote on releasing this package as Apache Calcite 1.22.0. The vote is open for the next 72 hours and passes if a majority of at least three +1 PMC votes are cast. [ ] +1 Release this package as Apache Calcite 1.22.0 [ ] 0 I don't feel strongly about it, but I'm okay with the release [ ] -1 Do not release this package because... Here is my vote: +1 (binding) Best, Danny Chan
[jira] [Created] (CALCITE-3833) Support SemiJoin in EnumerableMergeJoin
Ruben Q L created CALCITE-3833: -- Summary: Support SemiJoin in EnumerableMergeJoin Key: CALCITE-3833 URL: https://issues.apache.org/jira/browse/CALCITE-3833 Project: Calcite Issue Type: New Feature Components: core Affects Versions: 1.21.0 Reporter: Ruben Q L Assignee: Ruben Q L Currently, EnumerableMergeJoin only supports INNER joins. The goal of this ticket is to improve this join operator in order to support SEMI joins too. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-3834) Support AntiJoin in EnumerableMergeJoin
Ruben Q L created CALCITE-3834: -- Summary: Support AntiJoin in EnumerableMergeJoin Key: CALCITE-3834 URL: https://issues.apache.org/jira/browse/CALCITE-3834 Project: Calcite Issue Type: New Feature Components: core Affects Versions: 1.21.0 Reporter: Ruben Q L Assignee: Ruben Q L Currently, EnumerableMergeJoin only supports INNER joins. The goal of this ticket is to improve this join operator in order to support ANTI joins too. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Problems on RC with HerdDB: was: [VOTE] Release apache-calcite-1.22.0 (release candidate 0)
I have attached a reproducer testcase for my problem. The problem is not in the planner itself but in the Sql to Rel conversion https://issues.apache.org/jira/browse/CALCITE-3826 I am sorry I am not able to open Calcite with IntelliJ nor NetBeans. I can push the producer to a github repo if you prefer, it is a simpler JUnit based test case Hope this helps Enrico Il giorno mar 25 feb 2020 alle ore 14:50 Enrico Olivelli ha scritto: > > Il giorno mar 25 feb 2020 alle ore 14:43 Vladimir Sitnikov > ha scritto: > > > > >Does any ring bell ? > > > > Is it related to [CALCITE-3672] Support implicit type coercion for insert > > and update ? > > https://issues.apache.org/jira/browse/CALCITE-3672 > > https://github.com/apache/calcite/pull/1720 > > > Vladimir, Danny, > yes I think that that patch can be the trigger of the regression. > I see that tests do not deal with bind variables. > > I wonder if there is some way to disable the new behaviour > otherwise I feel this can be a real blocker for the release. > > > > > > > >I am now trying to install IntelliJ, but it won't be so immediate > > > > AFAIK it should be seamless, so please follow up if you run into issues. > > I am able to open the project, I just have to get used to IntelliJ, no > problem. > > Enrico > > > > > Vladimir
Re: [VOTE] Release apache-calcite-1.22.0 (release candidate 2)
With the help of Stamatis we have created a reproducer the attached test case (in the last comment) fails on current master (and 1.22.0rc) but does not fail on 1.21 so it can be considered a real regression Stamatis created a test case for Calcite code base, that can be used by a developer to fix the issue https://issues.apache.org/jira/browse/CALCITE-3826 I am sorry I am not able to work on it these days Enrico Il giorno gio 27 feb 2020 alle ore 09:29 Julian Hyde ha scritto: > > Danny > > I agree that a -1 is disheartening. Especially when given for mistaken > reasons. > > Technically a -1 does not kill an RC. We just need 3 more +1 votes than -1 > votes. > > I urge everyone to give detailed rationale for their vote. Even if you vote > +1, describe what you checked. > > Julian > > > On Feb 26, 2020, at 03:14, Danny Chan wrote: > > > > Gives a -1 when you are sure that it is a bug, or the voting would be very > > depressing, anyone can give a -1 for any reasons. > > > > Best, > > Danny Chan > > 在 2020年2月26日 +0800 PM3:04，Enrico Olivelli ，写道： > >> Danny, > >> I have created https://issues.apache.org/jira/browse/CALCITE-3826 > >> for the problem about bind variables in UPDATE statements. > >> > >> I feel this it can be a serious regression that can lead to data > >> corruption (wrong data type in DML statements). > >> AFAICT There is no way to workaround the problem in the application, > >> because Calcite produces a wrong model for the query. > >> > >> It seems to be a regression introduced in > >> https://issues.apache.org/jira/browse/CALCITE-3672 but I am not sure. > >> we should confirm the bug and fix it or demonstrate that the bug is not > >> valid > >> > >> -1 (non binding) > >> > >> Enrico > >> > >>> Il giorno mer 26 feb 2020 alle ore 07:34 Feng Zhu > >>> ha scritto: > >>> > >>> Hi Danny, > >>> Thanks for your efforts. > >>> > >>> +1 (non-binding) > >>> > >>> Environment: Windows 7, JDK 1.8.0_121 > >>> - Build and Test (./gradlew build) - OK > >>> - Checked Release Notes - OK > >>> - Checked README - OK > >>> > >>> Best, > >>> Feng > >>> > >>> Danny Chan 于2020年2月26日周三 下午1:23写道： > >>> > Hi all, > > I have created a build for Apache Calcite 1.22.0, release candidate 2. > > Thanks to everyone who has contributed to this release. > You can read the release notes here: > https://github.com/apache/calcite/blob/calcite-1.22.0/site/_docs/history.md > > The commit to be voted upon: > > https://gitbox.apache.org/repos/asf?p=calcite.git;a=commit;h=e397e47b0752c0647590097584903a9561a646eb > > Its hash is e397e47b0752c0647590097584903a9561a646eb. > > The artifacts to be voted on are located here: > https://dist.apache.org/repos/dist/dev/calcite/apache-calcite-1.22.0-rc2/ > > The hashes of the artifacts are as follows: > src.tar.gz.sha512 > > 049a7650645106589b8fa65adf36ebbe90accf8359bcc05f40d7b50b00df9327b24b189c4cd1c0e12a702635cc1dc41f9e8b60238073bf83dfcff9c0ef60e66a > *apache-calcite-1.22.0-src.tar.gz > > A staged Maven repository is available for review at: > https://repository.apache.org/content/repositories/orgapachecalcite-1079 > > Release artifacts are signed with the following key: > https://people.apache.org/keys/committer/danny0405.asc > > Please vote on releasing this package as Apache Calcite 1.22.0. > > The vote is open for the next 72 hours and passes if a majority of > at least three +1 PMC votes are cast. > > [ ] +1 Release this package as Apache Calcite 1.22.0 > [ ] 0 I don't feel strongly about it, but I'm okay with the release > [ ] -1 Do not release this package because... > > Here is my vote: > > +1 (binding) > > Best, > Danny Chan >
[jira] [Created] (CALCITE-3835) Overloaded table functions fail with an assertion error if param types differ
Vova Vysotskyi created CALCITE-3835:
---
Summary: Overloaded table functions fail with an assertion error
if param types differ
Key: CALCITE-3835
URL: https://issues.apache.org/jira/browse/CALCITE-3835
Project: Calcite
Issue Type: Bug
Reporter: Vova Vysotskyi
Assignee: Vova Vysotskyi
Fix For: 1.23.0
For the case of using named parameters in table functions, when several table
functions with the same name, but with different argument types, query with
such function fails with an assertion error.
For example, the following table functions:
{{View(String R, String S, Integer T)}} and {{View(String R, String S, Integer
T, String S2)}}
will fail with assertion error for the following query:
{code:sql}
select * from table("adhoc"."View"(t=>5, s=>'6'))
{code}
with error:
{noformat}
VARCHAR
java.lang.AssertionError: VARCHAR
at
org.apache.calcite.sql.type.SqlTypeExplicitPrecedenceList.compareTypePrecedence(SqlTypeExplicitPrecedenceList.java:139)
at org.apache.calcite.sql.SqlUtil.bestMatch(SqlUtil.java:691)
at
org.apache.calcite.sql.SqlUtil.filterRoutinesByTypePrecedence(SqlUtil.java:660)
at
org.apache.calcite.sql.SqlUtil.lookupSubjectRoutines(SqlUtil.java:519)
at org.apache.calcite.sql.SqlUtil.lookupRoutine(SqlUtil.java:439)
at org.apache.calcite.sql.SqlFunction.deriveType(SqlFunction.java:240)
at org.apache.calcite.sql.SqlFunction.deriveType(SqlFunction.java:218)
at
org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5854)
at
org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5841)
at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:139)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.deriveTypeImpl(SqlValidatorImpl.java:1800)
at
org.apache.calcite.sql.validate.ProcedureNamespace.validateImpl(ProcedureNamespace.java:53)
at
org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:1110)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:1084)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateFrom(SqlValidatorImpl.java:3256)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateFrom(SqlValidatorImpl.java:3238)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3510)
at
org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:60)
at
org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:1110)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:1084)
at org.apache.calcite.sql.SqlSelect.validate(SqlSelect.java:232)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:1059)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validate(SqlValidatorImpl.java:766)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:565)
at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:241)
at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:207)
at
org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:634)
at
org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:498)
at
org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:468)
at
org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:231)
at
org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:550)
at
org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:675)
at
org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:156)
at
org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:227)
at
org.apache.calcite.test.CalciteAssert.assertQuery(CalciteAssert.java:533)
at
org.apache.calcite.test.CalciteAssert$AssertQuery.lambda$returns$1(CalciteAssert.java:1519)
at
org.apache.calcite.test.CalciteAssert$AssertQuery.withConnection(CalciteAssert.java:1451)
at
org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1517)
at
org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1500)
at
org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAss
Re: [DISCUSS] Code freeze policy during release
I had not been very active for some time and I did not see this message in the mailing list. I am responsible for pushing some of those commits while the release is going on; I am sorry about that. Iirc we could force commit on master? I can fix it if you think it's the right thing to do. Thanks, Jesús On Wed, Feb 26, 2020 at 10:50 AM Michael Mior wrote: > I don't believe we have ever articulated an "official" policy on this. > But yes, it's generally expected that once the process of preparing a > release has started, no one will commit to master without checking > with the release manager. It's up to this person to judge whether a > commit is important/safe enough to include into the release. I haven't > checked who authored these commits, but I'm going to assume the > possibility they were not aware of a release in progress. This is a > good reminder to all committers to keep aware of the release cycle. > -- > Michael Mior > mm...@apache.org > > Le mer. 26 févr. 2020 à 09:33, Stamatis Zampetakis a > écrit : > > > > Hello, > > > > As far as I remember [1, 2, 3] the commits on master are suspended during > > the release process. > > In principle, if there is a commit that should go in it should pass by > the > > release manager and its up to him to decide if he wants to include it or > > not. > > Now if I am missing something I leave the more senior members fill in the > > details. > > > > Best, > > Stamatis > > > > [1] > > > https://lists.apache.org/thread.html/5cfea82c9e14d921e80ab3beb35d508996d18de1d45dd61404b21ca1%40%3Cdev.calcite.apache.org%3E > > [2] > > > https://lists.apache.org/thread.html/1d2d226d501154aa909364c0f954da7f41e401e92013129d772d041c%40%3Cdev.calcite.apache.org%3E > > [3] > > > https://lists.apache.org/thread.html/4402577cc2a596e0b221bbde53cac9f0d88568373d337f435199eb46%40%3Cdev.calcite.apache.org%3E > > > > On Wed, Feb 26, 2020 at 3:12 PM Chunwei Lei > wrote: > > > > > Thanks for pointing out this, Ruben. I also have this question. > > > > > > But in our scrum, we can merge commits to master at the moment we have > a > > > release branch. > > > > > > > > > Best, > > > Chunwei > > > > > > > > > On Wed, Feb 26, 2020 at 8:52 PM Ruben Q L wrote: > > > > > > > Hello everyone, > > > > > > > > as you know, we are in the middle of the release process for 1.22 > (btw, > > > > thanks Danny for your effort as release manager). > > > > However, if I am not mistaken I can see that some PRs have been > merged > > > > during this time, at least [1] and [2]. I am wondering if during this > > > > process (from the build of the first release candidate to the final > > > > approval of the release), we should not be in some kind of "code > freeze", > > > > where commits are not allowed, unless they are explicitly approved > > > > (ultimately by the release manager, I guess) in order to solve issues > > > with > > > > the release candidates (e.g. [3]). Is there any rule / guideline > about > > > > this? > > > > > > > > Best regards, > > > > Ruben. > > > > > > > > [1] https://issues.apache.org/jira/browse/CALCITE-3817 > > > > [2] https://issues.apache.org/jira/browse/CALCITE-3734 > > > > < > > > > > > > > https://slack-redir.net/link?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FCALCITE-3734&v=3 > > > > > > > > > [3] https://issues.apache.org/jira/browse/CALCITE-3822 > > > > > > > >
Re: [VOTE] Release apache-calcite-1.22.0 (release candidate 2)
Hi Danny, Thanks a lot for all Danny's contributions so far on this release! verified on platform: 5.2.17-1rodete3-amd64 - calcite-1.22.0 tag has the right commit which is upon voting. OK - check artifacts 512 hash (run sha512sum locally). OK - run "./gradlew :assemble" from sources extracted from apache-calcite-1.22.0-src.zip but cannot build from it: Execution failed for task ':buildSrc:autostyleKotlinGradleCheck'. - cannot verify signature on artifacts by: "gpg --verify apache-calcite-1.22.0-src.zip.asc apache-calcite-1.22.0-src.zip" gpg: Signature made Tue 25 Feb 2020 08:47:33 PM PST gpg:using RSA key 9A48922F682AB05D1AE4A3E7C2931E4BDB03D5AE gpg: Can't check signature: No public key -1 (non-binding) I will check again on my mac platform tonight. -Rui On Thu, Feb 27, 2020 at 7:40 AM Enrico Olivelli wrote: > With the help of Stamatis > we have created a reproducer > the attached test case (in the last comment) fails on current master > (and 1.22.0rc) but does not fail on 1.21 > so it can be considered a real regression > > Stamatis created a test case for Calcite code base, that can be used > by a developer to fix the issue > https://issues.apache.org/jira/browse/CALCITE-3826 > > I am sorry I am not able to work on it these days > > Enrico > > > Il giorno gio 27 feb 2020 alle ore 09:29 Julian Hyde > ha scritto: > > > > Danny > > > > I agree that a -1 is disheartening. Especially when given for mistaken > reasons. > > > > Technically a -1 does not kill an RC. We just need 3 more +1 votes than > -1 votes. > > > > I urge everyone to give detailed rationale for their vote. Even if you > vote +1, describe what you checked. > > > > Julian > > > > > On Feb 26, 2020, at 03:14, Danny Chan wrote: > > > > > > Gives a -1 when you are sure that it is a bug, or the voting would be > very depressing, anyone can give a -1 for any reasons. > > > > > > Best, > > > Danny Chan > > > 在 2020年2月26日 +0800 PM3:04，Enrico Olivelli ，写道： > > >> Danny, > > >> I have created https://issues.apache.org/jira/browse/CALCITE-3826 > > >> for the problem about bind variables in UPDATE statements. > > >> > > >> I feel this it can be a serious regression that can lead to data > > >> corruption (wrong data type in DML statements). > > >> AFAICT There is no way to workaround the problem in the application, > > >> because Calcite produces a wrong model for the query. > > >> > > >> It seems to be a regression introduced in > > >> https://issues.apache.org/jira/browse/CALCITE-3672 but I am not sure. > > >> we should confirm the bug and fix it or demonstrate that the bug is > not valid > > >> > > >> -1 (non binding) > > >> > > >> Enrico > > >> > > >>> Il giorno mer 26 feb 2020 alle ore 07:34 Feng Zhu > > >>> ha scritto: > > >>> > > >>> Hi Danny, > > >>> Thanks for your efforts. > > >>> > > >>> +1 (non-binding) > > >>> > > >>> Environment: Windows 7, JDK 1.8.0_121 > > >>> - Build and Test (./gradlew build) - OK > > >>> - Checked Release Notes - OK > > >>> - Checked README - OK > > >>> > > >>> Best, > > >>> Feng > > >>> > > >>> Danny Chan 于2020年2月26日周三 下午1:23写道： > > >>> > > Hi all, > > > > I have created a build for Apache Calcite 1.22.0, release candidate > 2. > > > > Thanks to everyone who has contributed to this release. > > You can read the release notes > here: > > > https://github.com/apache/calcite/blob/calcite-1.22.0/site/_docs/history.md > > > > The commit to be voted upon: > > > > > https://gitbox.apache.org/repos/asf?p=calcite.git;a=commit;h=e397e47b0752c0647590097584903a9561a646eb > > > > Its hash is e397e47b0752c0647590097584903a9561a646eb. > > > > The artifacts to be voted on are located here: > > > https://dist.apache.org/repos/dist/dev/calcite/apache-calcite-1.22.0-rc2/ > > > > The hashes of the artifacts are as follows: > > src.tar.gz.sha512 > > > > > 049a7650645106589b8fa65adf36ebbe90accf8359bcc05f40d7b50b00df9327b24b189c4cd1c0e12a702635cc1dc41f9e8b60238073bf83dfcff9c0ef60e66a > > *apache-calcite-1.22.0-src.tar.gz > > > > A staged Maven repository is available for review at: > > > https://repository.apache.org/content/repositories/orgapachecalcite-1079 > > > > Release artifacts are signed with the following key: > > https://people.apache.org/keys/committer/danny0405.asc > > > > Please vote on releasing this package as Apache Calcite 1.22.0. > > > > The vote is open for the next 72 hours and passes if a majority of > > at least three +1 PMC votes are cast. > > > > [ ] +1 Release this package as Apache Calcite 1.22.0 > > [ ] 0 I don't feel strongly about it, but I'm okay with the release > > [ ] -1 Do not release this package because... > > > > Here is my vote: > > > > +1 (binding) > > > > Best, > > Danny Chan > > >
Re: [DISCUSS] Code freeze policy during release
I think the best course is that the release manager (Danny) rebases master after the RC has been accepted, just before he re-openes the master branch. The SHAs of your commits will change, but this is unavoidable. > On Feb 27, 2020, at 10:58 AM, Jesus Camacho Rodriguez > wrote: > > I had not been very active for some time and I did not see this message in > the mailing list. > > I am responsible for pushing some of those commits while the release is > going on; I am sorry about that. Iirc we could force commit on master? I > can fix it if you think it's the right thing to do. > > Thanks, > Jesús > > On Wed, Feb 26, 2020 at 10:50 AM Michael Mior wrote: > >> I don't believe we have ever articulated an "official" policy on this. >> But yes, it's generally expected that once the process of preparing a >> release has started, no one will commit to master without checking >> with the release manager. It's up to this person to judge whether a >> commit is important/safe enough to include into the release. I haven't >> checked who authored these commits, but I'm going to assume the >> possibility they were not aware of a release in progress. This is a >> good reminder to all committers to keep aware of the release cycle. >> -- >> Michael Mior >> mm...@apache.org >> >> Le mer. 26 févr. 2020 à 09:33, Stamatis Zampetakis a >> écrit : >>> >>> Hello, >>> >>> As far as I remember [1, 2, 3] the commits on master are suspended during >>> the release process. >>> In principle, if there is a commit that should go in it should pass by >> the >>> release manager and its up to him to decide if he wants to include it or >>> not. >>> Now if I am missing something I leave the more senior members fill in the >>> details. >>> >>> Best, >>> Stamatis >>> >>> [1] >>> >> https://lists.apache.org/thread.html/5cfea82c9e14d921e80ab3beb35d508996d18de1d45dd61404b21ca1%40%3Cdev.calcite.apache.org%3E >>> [2] >>> >> https://lists.apache.org/thread.html/1d2d226d501154aa909364c0f954da7f41e401e92013129d772d041c%40%3Cdev.calcite.apache.org%3E >>> [3] >>> >> https://lists.apache.org/thread.html/4402577cc2a596e0b221bbde53cac9f0d88568373d337f435199eb46%40%3Cdev.calcite.apache.org%3E >>> >>> On Wed, Feb 26, 2020 at 3:12 PM Chunwei Lei >> wrote: >>> Thanks for pointing out this, Ruben. I also have this question. But in our scrum, we can merge commits to master at the moment we have >> a release branch. Best, Chunwei On Wed, Feb 26, 2020 at 8:52 PM Ruben Q L wrote: > Hello everyone, > > as you know, we are in the middle of the release process for 1.22 >> (btw, > thanks Danny for your effort as release manager). > However, if I am not mistaken I can see that some PRs have been >> merged > during this time, at least [1] and [2]. I am wondering if during this > process (from the build of the first release candidate to the final > approval of the release), we should not be in some kind of "code >> freeze", > where commits are not allowed, unless they are explicitly approved > (ultimately by the release manager, I guess) in order to solve issues with > the release candidates (e.g. [3]). Is there any rule / guideline >> about > this? > > Best regards, > Ruben. > > [1] https://issues.apache.org/jira/browse/CALCITE-3817 > [2] https://issues.apache.org/jira/browse/CALCITE-3734 > < > >> https://slack-redir.net/link?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FCALCITE-3734&v=3 >> > [3] https://issues.apache.org/jira/browse/CALCITE-3822 > >>
Re: [DISCUSS] Code freeze policy during release
Makes sense; I will modify the commit messages in those JIRAs accordingly once they are pushed again. -Jesús On Thu, Feb 27, 2020 at 1:38 PM Julian Hyde wrote: > I think the best course is that the release manager (Danny) rebases master > after the RC has been accepted, just before he re-openes the master branch. > The SHAs of your commits will change, but this is unavoidable. > > > On Feb 27, 2020, at 10:58 AM, Jesus Camacho Rodriguez > wrote: > > > > I had not been very active for some time and I did not see this message > in > > the mailing list. > > > > I am responsible for pushing some of those commits while the release is > > going on; I am sorry about that. Iirc we could force commit on master? I > > can fix it if you think it's the right thing to do. > > > > Thanks, > > Jesús > > > > On Wed, Feb 26, 2020 at 10:50 AM Michael Mior wrote: > > > >> I don't believe we have ever articulated an "official" policy on this. > >> But yes, it's generally expected that once the process of preparing a > >> release has started, no one will commit to master without checking > >> with the release manager. It's up to this person to judge whether a > >> commit is important/safe enough to include into the release. I haven't > >> checked who authored these commits, but I'm going to assume the > >> possibility they were not aware of a release in progress. This is a > >> good reminder to all committers to keep aware of the release cycle. > >> -- > >> Michael Mior > >> mm...@apache.org > >> > >> Le mer. 26 févr. 2020 à 09:33, Stamatis Zampetakis > a > >> écrit : > >>> > >>> Hello, > >>> > >>> As far as I remember [1, 2, 3] the commits on master are suspended > during > >>> the release process. > >>> In principle, if there is a commit that should go in it should pass by > >> the > >>> release manager and its up to him to decide if he wants to include it > or > >>> not. > >>> Now if I am missing something I leave the more senior members fill in > the > >>> details. > >>> > >>> Best, > >>> Stamatis > >>> > >>> [1] > >>> > >> > https://lists.apache.org/thread.html/5cfea82c9e14d921e80ab3beb35d508996d18de1d45dd61404b21ca1%40%3Cdev.calcite.apache.org%3E > >>> [2] > >>> > >> > https://lists.apache.org/thread.html/1d2d226d501154aa909364c0f954da7f41e401e92013129d772d041c%40%3Cdev.calcite.apache.org%3E > >>> [3] > >>> > >> > https://lists.apache.org/thread.html/4402577cc2a596e0b221bbde53cac9f0d88568373d337f435199eb46%40%3Cdev.calcite.apache.org%3E > >>> > >>> On Wed, Feb 26, 2020 at 3:12 PM Chunwei Lei > >> wrote: > >>> > Thanks for pointing out this, Ruben. I also have this question. > > But in our scrum, we can merge commits to master at the moment we have > >> a > release branch. > > > Best, > Chunwei > > > On Wed, Feb 26, 2020 at 8:52 PM Ruben Q L wrote: > > > Hello everyone, > > > > as you know, we are in the middle of the release process for 1.22 > >> (btw, > > thanks Danny for your effort as release manager). > > However, if I am not mistaken I can see that some PRs have been > >> merged > > during this time, at least [1] and [2]. I am wondering if during this > > process (from the build of the first release candidate to the final > > approval of the release), we should not be in some kind of "code > >> freeze", > > where commits are not allowed, unless they are explicitly approved > > (ultimately by the release manager, I guess) in order to solve issues > with > > the release candidates (e.g. [3]). Is there any rule / guideline > >> about > > this? > > > > Best regards, > > Ruben. > > > > [1] https://issues.apache.org/jira/browse/CALCITE-3817 > > [2] https://issues.apache.org/jira/browse/CALCITE-3734 > > < > > > > >> > https://slack-redir.net/link?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FCALCITE-3734&v=3 > >> > > [3] https://issues.apache.org/jira/browse/CALCITE-3822 > > > > >> > >
Re: [DISCUSS] Code freeze policy during release
While you rebase you can also squash the two commits you made for CALCITE-3825 into one. > On Feb 27, 2020, at 1:55 PM, Jesus Camacho Rodriguez > wrote: > > Makes sense; I will modify the commit messages in those JIRAs accordingly > once they are pushed again. > > -Jesús > > On Thu, Feb 27, 2020 at 1:38 PM Julian Hyde wrote: > >> I think the best course is that the release manager (Danny) rebases master >> after the RC has been accepted, just before he re-openes the master branch. >> The SHAs of your commits will change, but this is unavoidable. >> >>> On Feb 27, 2020, at 10:58 AM, Jesus Camacho Rodriguez >> wrote: >>> >>> I had not been very active for some time and I did not see this message >> in >>> the mailing list. >>> >>> I am responsible for pushing some of those commits while the release is >>> going on; I am sorry about that. Iirc we could force commit on master? I >>> can fix it if you think it's the right thing to do. >>> >>> Thanks, >>> Jesús >>> >>> On Wed, Feb 26, 2020 at 10:50 AM Michael Mior wrote: >>> I don't believe we have ever articulated an "official" policy on this. But yes, it's generally expected that once the process of preparing a release has started, no one will commit to master without checking with the release manager. It's up to this person to judge whether a commit is important/safe enough to include into the release. I haven't checked who authored these commits, but I'm going to assume the possibility they were not aware of a release in progress. This is a good reminder to all committers to keep aware of the release cycle. -- Michael Mior mm...@apache.org Le mer. 26 févr. 2020 à 09:33, Stamatis Zampetakis >> a écrit : > > Hello, > > As far as I remember [1, 2, 3] the commits on master are suspended >> during > the release process. > In principle, if there is a commit that should go in it should pass by the > release manager and its up to him to decide if he wants to include it >> or > not. > Now if I am missing something I leave the more senior members fill in >> the > details. > > Best, > Stamatis > > [1] > >> https://lists.apache.org/thread.html/5cfea82c9e14d921e80ab3beb35d508996d18de1d45dd61404b21ca1%40%3Cdev.calcite.apache.org%3E > [2] > >> https://lists.apache.org/thread.html/1d2d226d501154aa909364c0f954da7f41e401e92013129d772d041c%40%3Cdev.calcite.apache.org%3E > [3] > >> https://lists.apache.org/thread.html/4402577cc2a596e0b221bbde53cac9f0d88568373d337f435199eb46%40%3Cdev.calcite.apache.org%3E > > On Wed, Feb 26, 2020 at 3:12 PM Chunwei Lei wrote: > >> Thanks for pointing out this, Ruben. I also have this question. >> >> But in our scrum, we can merge commits to master at the moment we have a >> release branch. >> >> >> Best, >> Chunwei >> >> >> On Wed, Feb 26, 2020 at 8:52 PM Ruben Q L wrote: >> >>> Hello everyone, >>> >>> as you know, we are in the middle of the release process for 1.22 (btw, >>> thanks Danny for your effort as release manager). >>> However, if I am not mistaken I can see that some PRs have been merged >>> during this time, at least [1] and [2]. I am wondering if during this >>> process (from the build of the first release candidate to the final >>> approval of the release), we should not be in some kind of "code freeze", >>> where commits are not allowed, unless they are explicitly approved >>> (ultimately by the release manager, I guess) in order to solve issues >> with >>> the release candidates (e.g. [3]). Is there any rule / guideline about >>> this? >>> >>> Best regards, >>> Ruben. >>> >>> [1] https://issues.apache.org/jira/browse/CALCITE-3817 >>> [2] https://issues.apache.org/jira/browse/CALCITE-3734 >>> < >>> >> >> https://slack-redir.net/link?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FCALCITE-3734&v=3 >>> [3] https://issues.apache.org/jira/browse/CALCITE-3822 >>> >> >> >>
Re: [DISCUSS] Code freeze policy during release
I am sorry that I merged a commit while the release is going on too. I see Julain suggests the release manager(Danny) rebase master. Danny, please feel free to tell me if I can do some help. Thank you for your effort~~ Best, Chunwei On Fri, Feb 28, 2020 at 6:17 AM Julian Hyde wrote: > While you rebase you can also squash the two commits you made for > CALCITE-3825 into one. > > > On Feb 27, 2020, at 1:55 PM, Jesus Camacho Rodriguez < > jcama...@apache.org> wrote: > > > > Makes sense; I will modify the commit messages in those JIRAs accordingly > > once they are pushed again. > > > > -Jesús > > > > On Thu, Feb 27, 2020 at 1:38 PM Julian Hyde wrote: > > > >> I think the best course is that the release manager (Danny) rebases > master > >> after the RC has been accepted, just before he re-openes the master > branch. > >> The SHAs of your commits will change, but this is unavoidable. > >> > >>> On Feb 27, 2020, at 10:58 AM, Jesus Camacho Rodriguez > >> wrote: > >>> > >>> I had not been very active for some time and I did not see this message > >> in > >>> the mailing list. > >>> > >>> I am responsible for pushing some of those commits while the release is > >>> going on; I am sorry about that. Iirc we could force commit on master? > I > >>> can fix it if you think it's the right thing to do. > >>> > >>> Thanks, > >>> Jesús > >>> > >>> On Wed, Feb 26, 2020 at 10:50 AM Michael Mior > wrote: > >>> > I don't believe we have ever articulated an "official" policy on this. > But yes, it's generally expected that once the process of preparing a > release has started, no one will commit to master without checking > with the release manager. It's up to this person to judge whether a > commit is important/safe enough to include into the release. I haven't > checked who authored these commits, but I'm going to assume the > possibility they were not aware of a release in progress. This is a > good reminder to all committers to keep aware of the release cycle. > -- > Michael Mior > mm...@apache.org > > Le mer. 26 févr. 2020 à 09:33, Stamatis Zampetakis > > >> a > écrit : > > > > Hello, > > > > As far as I remember [1, 2, 3] the commits on master are suspended > >> during > > the release process. > > In principle, if there is a commit that should go in it should pass > by > the > > release manager and its up to him to decide if he wants to include it > >> or > > not. > > Now if I am missing something I leave the more senior members fill in > >> the > > details. > > > > Best, > > Stamatis > > > > [1] > > > > >> > https://lists.apache.org/thread.html/5cfea82c9e14d921e80ab3beb35d508996d18de1d45dd61404b21ca1%40%3Cdev.calcite.apache.org%3E > > [2] > > > > >> > https://lists.apache.org/thread.html/1d2d226d501154aa909364c0f954da7f41e401e92013129d772d041c%40%3Cdev.calcite.apache.org%3E > > [3] > > > > >> > https://lists.apache.org/thread.html/4402577cc2a596e0b221bbde53cac9f0d88568373d337f435199eb46%40%3Cdev.calcite.apache.org%3E > > > > On Wed, Feb 26, 2020 at 3:12 PM Chunwei Lei > wrote: > > > >> Thanks for pointing out this, Ruben. I also have this question. > >> > >> But in our scrum, we can merge commits to master at the moment we > have > a > >> release branch. > >> > >> > >> Best, > >> Chunwei > >> > >> > >> On Wed, Feb 26, 2020 at 8:52 PM Ruben Q L > wrote: > >> > >>> Hello everyone, > >>> > >>> as you know, we are in the middle of the release process for 1.22 > (btw, > >>> thanks Danny for your effort as release manager). > >>> However, if I am not mistaken I can see that some PRs have been > merged > >>> during this time, at least [1] and [2]. I am wondering if during > this > >>> process (from the build of the first release candidate to the final > >>> approval of the release), we should not be in some kind of "code > freeze", > >>> where commits are not allowed, unless they are explicitly approved > >>> (ultimately by the release manager, I guess) in order to solve > issues > >> with > >>> the release candidates (e.g. [3]). Is there any rule / guideline > about > >>> this? > >>> > >>> Best regards, > >>> Ruben. > >>> > >>> [1] https://issues.apache.org/jira/browse/CALCITE-3817 > >>> [2] https://issues.apache.org/jira/browse/CALCITE-3734 > >>> < > >>> > >> > > >> > https://slack-redir.net/link?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FCALCITE-3734&v=3 > > >>> [3] https://issues.apache.org/jira/browse/CALCITE-3822 > >>> > >> > > >> > >> > >
Re: [VOTE] Release apache-calcite-1.22.0 (release candidate 2)
Why you verify the zip from a source distribution ? There is no key file there. I verify the zip files manually from https://dist.apache.org/repos/dist/dev/calcite/apache-calcite-1.22.0-rc2/ With command gpg --verify apache-calcite-1.22.0-src.zip.asc apache-calcite-1.22.0-src.zip And it outputs: gpg: 签名建立于 三 2/26 12:47:33 2020 CST gpg: 使用 RSA 密钥 9A48922F682AB05D1AE4A3E7C2931E4BDB03D5AE gpg: 完好的签名，来自于 “Danny Chan (yuzhao.cyz gpg) ” [绝对] Best, Danny Chan 在 2020年2月28日 +0800 AM5:13，Rui Wang ，写道： > Hi Danny, > > Thanks a lot for all Danny's contributions so far on this release! > > verified on platform: 5.2.17-1rodete3-amd64 > > - calcite-1.22.0 tag has the right commit which is upon voting. OK > - check artifacts 512 hash (run sha512sum locally). OK > > > - run "./gradlew :assemble" from sources extracted from > apache-calcite-1.22.0-src.zip but cannot build from it: > Execution failed for task ':buildSrc:autostyleKotlinGradleCheck'. > - cannot verify signature on artifacts by: "gpg --verify > apache-calcite-1.22.0-src.zip.asc apache-calcite-1.22.0-src.zip" > gpg: Signature made Tue 25 Feb 2020 08:47:33 PM PST > gpg: using RSA key > 9A48922F682AB05D1AE4A3E7C2931E4BDB03D5AE > gpg: Can't check signature: No public key > > > -1 (non-binding) > > I will check again on my mac platform tonight. > > -Rui > > > On Thu, Feb 27, 2020 at 7:40 AM Enrico Olivelli wrote: > > > With the help of Stamatis > > we have created a reproducer > > the attached test case (in the last comment) fails on current master > > (and 1.22.0rc) but does not fail on 1.21 > > so it can be considered a real regression > > > > Stamatis created a test case for Calcite code base, that can be used > > by a developer to fix the issue > > https://issues.apache.org/jira/browse/CALCITE-3826 > > > > I am sorry I am not able to work on it these days > > > > Enrico > > > > > > Il giorno gio 27 feb 2020 alle ore 09:29 Julian Hyde > > ha scritto: > > > > > > Danny > > > > > > I agree that a -1 is disheartening. Especially when given for mistaken > > reasons. > > > > > > Technically a -1 does not kill an RC. We just need 3 more +1 votes than > > -1 votes. > > > > > > I urge everyone to give detailed rationale for their vote. Even if you > > vote +1, describe what you checked. > > > > > > Julian > > > > > > > On Feb 26, 2020, at 03:14, Danny Chan wrote: > > > > > > > > Gives a -1 when you are sure that it is a bug, or the voting would be > > very depressing, anyone can give a -1 for any reasons. > > > > > > > > Best, > > > > Danny Chan > > > > 在 2020年2月26日 +0800 PM3:04，Enrico Olivelli ，写道： > > > > > Danny, > > > > > I have created https://issues.apache.org/jira/browse/CALCITE-3826 > > > > > for the problem about bind variables in UPDATE statements. > > > > > > > > > > I feel this it can be a serious regression that can lead to data > > > > > corruption (wrong data type in DML statements). > > > > > AFAICT There is no way to workaround the problem in the application, > > > > > because Calcite produces a wrong model for the query. > > > > > > > > > > It seems to be a regression introduced in > > > > > https://issues.apache.org/jira/browse/CALCITE-3672 but I am not sure. > > > > > we should confirm the bug and fix it or demonstrate that the bug is > > not valid > > > > > > > > > > -1 (non binding) > > > > > > > > > > Enrico > > > > > > > > > > > Il giorno mer 26 feb 2020 alle ore 07:34 Feng Zhu > > > > > > ha scritto: > > > > > > > > > > > > Hi Danny, > > > > > > Thanks for your efforts. > > > > > > > > > > > > +1 (non-binding) > > > > > > > > > > > > Environment: Windows 7, JDK 1.8.0_121 > > > > > > - Build and Test (./gradlew build) - OK > > > > > > - Checked Release Notes - OK > > > > > > - Checked README - OK > > > > > > > > > > > > Best, > > > > > > Feng > > > > > > > > > > > > Danny Chan 于2020年2月26日周三 下午1:23写道： > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > I have created a build for Apache Calcite 1.22.0, release > > > > > > > candidate > > 2. > > > > > > > > > > > > > > Thanks to everyone who has contributed to this release. > > > > > > > You can read the release notes > > here: > > > > > > > > > https://github.com/apache/calcite/blob/calcite-1.22.0/site/_docs/history.md > > > > > > > > > > > > > > The commit to be voted upon: > > > > > > > > > > > > > > > > https://gitbox.apache.org/repos/asf?p=calcite.git;a=commit;h=e397e47b0752c0647590097584903a9561a646eb > > > > > > > > > > > > > > Its hash is e397e47b0752c0647590097584903a9561a646eb. > > > > > > > > > > > > > > The artifacts to be voted on are located here: > > > > > > > > > https://dist.apache.org/repos/dist/dev/calcite/apache-calcite-1.22.0-rc2/ > > > > > > > > > > > > > > The hashes of the artifacts are as follows: > > > > > > > src.tar.gz.sha512 > > > > > > > > > > > > > > > > 049a7650645106589b8fa65adf36ebbe90accf8359bcc05f40d7b50b00df9327b24b189c4cd1c0e12a702635cc1dc41f9e8b60238073bf83dfcff9c0ef60e66a > > > > > > > *apache-calcite-1.22.0-src.tar.gz > > > > > > > > > >
Travis filed: net.hydromatic.foodmart.queries does not exist
The Travis failed recently very frequently, such as https://travis-ci.org/apache/calcite/jobs/656071104?utm_medium=notification&utm_source=github_status It always reports net.hydromatic.foodmart.queries does not exist Can someone help with that ? Best, Danny Chan
Calcite-Master - Build # 1627 - Still Failing
The Apache Jenkins build system has built Calcite-Master (build #1627) Status: Still Failing Check console output at https://builds.apache.org/job/Calcite-Master/1627/ to view the results.
Re: [VOTE] Release apache-calcite-1.22.0 (release candidate 2)
"gpg --verify apache-calcite-1.22.0-src.zip.asc apache-calcite-1.22.0-src.zip" is my understanding of how to verify the signature. I might have done it wrongly. Let's see how other people verify it. -Rui On Thu, Feb 27, 2020 at 7:50 PM Danny Chan wrote: > Why you verify the zip from a source distribution ? There is no key file > there. I verify the zip files manually from > https://dist.apache.org/repos/dist/dev/calcite/apache-calcite-1.22.0-rc2/ > > With command > gpg --verify apache-calcite-1.22.0-src.zip.asc > apache-calcite-1.22.0-src.zip > > And it outputs: > > gpg: 签名建立于 三 2/26 12:47:33 2020 CST > gpg: 使用 RSA 密钥 9A48922F682AB05D1AE4A3E7C2931E4BDB03D5AE > gpg: 完好的签名，来自于 “Danny Chan (yuzhao.cyz gpg) ” [绝对] > > Best, > Danny Chan > 在 2020年2月28日 +0800 AM5:13，Rui Wang ，写道： > > Hi Danny, > > > > Thanks a lot for all Danny's contributions so far on this release! > > > > verified on platform: 5.2.17-1rodete3-amd64 > > > > - calcite-1.22.0 tag has the right commit which is upon voting. OK > > - check artifacts 512 hash (run sha512sum locally). OK > > > > > > - run "./gradlew :assemble" from sources extracted from > > apache-calcite-1.22.0-src.zip but cannot build from it: > > Execution failed for task ':buildSrc:autostyleKotlinGradleCheck'. > > - cannot verify signature on artifacts by: "gpg --verify > > apache-calcite-1.22.0-src.zip.asc apache-calcite-1.22.0-src.zip" > > gpg: Signature made Tue 25 Feb 2020 08:47:33 PM PST > > gpg: using RSA key > > 9A48922F682AB05D1AE4A3E7C2931E4BDB03D5AE > > gpg: Can't check signature: No public key > > > > > > -1 (non-binding) > > > > I will check again on my mac platform tonight. > > > > -Rui > > > > > > On Thu, Feb 27, 2020 at 7:40 AM Enrico Olivelli > wrote: > > > > > With the help of Stamatis > > > we have created a reproducer > > > the attached test case (in the last comment) fails on current master > > > (and 1.22.0rc) but does not fail on 1.21 > > > so it can be considered a real regression > > > > > > Stamatis created a test case for Calcite code base, that can be used > > > by a developer to fix the issue > > > https://issues.apache.org/jira/browse/CALCITE-3826 > > > > > > I am sorry I am not able to work on it these days > > > > > > Enrico > > > > > > > > > Il giorno gio 27 feb 2020 alle ore 09:29 Julian Hyde > > > ha scritto: > > > > > > > > Danny > > > > > > > > I agree that a -1 is disheartening. Especially when given for > mistaken > > > reasons. > > > > > > > > Technically a -1 does not kill an RC. We just need 3 more +1 votes > than > > > -1 votes. > > > > > > > > I urge everyone to give detailed rationale for their vote. Even if > you > > > vote +1, describe what you checked. > > > > > > > > Julian > > > > > > > > > On Feb 26, 2020, at 03:14, Danny Chan > wrote: > > > > > > > > > > Gives a -1 when you are sure that it is a bug, or the voting would > be > > > very depressing, anyone can give a -1 for any reasons. > > > > > > > > > > Best, > > > > > Danny Chan > > > > > 在 2020年2月26日 +0800 PM3:04，Enrico Olivelli >，写道： > > > > > > Danny, > > > > > > I have created > https://issues.apache.org/jira/browse/CALCITE-3826 > > > > > > for the problem about bind variables in UPDATE statements. > > > > > > > > > > > > I feel this it can be a serious regression that can lead to data > > > > > > corruption (wrong data type in DML statements). > > > > > > AFAICT There is no way to workaround the problem in the > application, > > > > > > because Calcite produces a wrong model for the query. > > > > > > > > > > > > It seems to be a regression introduced in > > > > > > https://issues.apache.org/jira/browse/CALCITE-3672 but I am not > sure. > > > > > > we should confirm the bug and fix it or demonstrate that the bug > is > > > not valid > > > > > > > > > > > > -1 (non binding) > > > > > > > > > > > > Enrico > > > > > > > > > > > > > Il giorno mer 26 feb 2020 alle ore 07:34 Feng Zhu > > > > > > > ha scritto: > > > > > > > > > > > > > > Hi Danny, > > > > > > > Thanks for your efforts. > > > > > > > > > > > > > > +1 (non-binding) > > > > > > > > > > > > > > Environment: Windows 7, JDK 1.8.0_121 > > > > > > > - Build and Test (./gradlew build) - OK > > > > > > > - Checked Release Notes - OK > > > > > > > - Checked README - OK > > > > > > > > > > > > > > Best, > > > > > > > Feng > > > > > > > > > > > > > > Danny Chan 于2020年2月26日周三 下午1:23写道： > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > I have created a build for Apache Calcite 1.22.0, release > candidate > > > 2. > > > > > > > > > > > > > > > > Thanks to everyone who has contributed to this release. > > > > > > > > You can read the release > notes > > > here: > > > > > > > > > > > > https://github.com/apache/calcite/blob/calcite-1.22.0/site/_docs/history.md > > > > > > > > > > > > > > > > The commit to be voted upon: > > > > > > > > > > > > > > > > > > > > https://gitbox.apache.org/repos/asf?p=calcite.git;a=commit;h=e397e47b0752c0647590097584903a9561a646eb > > > > > > > > > > > > > > > > Its ha
[jira] [Created] (CALCITE-3836) The hash codes of RelNodes are unreliable
Liya Fan created CALCITE-3836:
-
Summary: The hash codes of RelNodes are unreliable
Key: CALCITE-3836
URL: https://issues.apache.org/jira/browse/CALCITE-3836
Project: Calcite
Issue Type: Bug
Components: core
Reporter: Liya Fan
For all sub-classes of AbstractRelNode, the {{hashCode}} methods depend on
{{AbstractRelNode#hashCode}}, because it is declared as final.
{{AbstractRelNode#hashCode}} depends on {{Object#hashCode}}, which is called
identify hash code. The details of identity hash code depends on the specific
JVM implementation. For many JVMs, the implementation is based on the object
address in the memory. The problem is that, the address of an object may change
in a JVM, due to GC, memory contraction, etc. So the hash code of an object may
change, even if the content of the object is not changed (This can be confirmed
from the JavaDoc of {{Object#hashCode}}).
This problem may cause severe issues that are hard to diagnose and debug, like
an object is in the hash table, but cannot be retrieved; duplicate objects in
the hash map, etc.
To solve the problem, we compute a hash code solely from the node id. This is
consistent with the previous semantics, and solves the above problem.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: Travis filed: net.hydromatic.foodmart.queries does not exist
I’ll take a look tomorrow. Julian > On Feb 27, 2020, at 8:06 PM, Danny Chan wrote: > > The Travis failed recently very frequently, such as > https://travis-ci.org/apache/calcite/jobs/656071104?utm_medium=notification&utm_source=github_status > > It always reports net.hydromatic.foodmart.queries does not exist > > Can someone help with that ? > > Best, > Danny Chan
