Re: [DISCUSS] Towards Calcite 1.34.0
+1 Stamatis, it's nice to help them out, thanks for being the RM On Fri 10 Mar 2023, 01:36 Benchao Li, wrote: > +1, Thanks Stamatis for driving this. > > Stamatis Zampetakis 于2023年3月10日周五 07:18写道： > > > Draft release notes: https://github.com/apache/calcite/pull/3103 > > > > On Thu, Mar 9, 2023 at 11:06 PM Charles Givre wrote: > > > > > +1. Thank you very much for doing this! > > > -- C > > > > > > > > > > > > > > > > On Mar 9, 2023, at 5:01 PM, Francis Chuang > > > > wrote: > > > > > > > > +1 Thanks for being RM, Stamatis! > > > > > > > > On 10/03/2023 8:57 am, Stamatis Zampetakis wrote: > > > >> Hello, > > > >> It's been a bit more than a month since our last release [1] and > there > > > are > > > >> currently ~30 new commits in master. > > > >> Although we could wait a bit longer before cutting a new release, it > > > would > > > >> be nice to facilitate Drills efforts [2] in upgrading to the latest > > > Calcite > > > >> release by providing a version with the fix for the small breaking > > > change > > > >> reported under CALCITE-5522. > > > >> If there are no objections, I will create an RC in the following > days. > > > >> If there are other must fix for 1.34.0 please let us know so that we > > can > > > >> plan accordingly. > > > >> Best, > > > >> Stamatis > > > >> [1] https://calcite.apache.org/docs/history.html#v1-33-0 > > > >> [2] > https://lists.apache.org/thread/yo4075khphgbw1dzzo6w4kpvyl7280x9 > > > > > > > > > > > -- > > Best, > Benchao Li >
Re: [DISCUSS] Towards Calcite 1.34.0
+1, Thank you for being the RM Best, Dan Zou > 2023年3月10日 07:18，Stamatis Zampetakis 写道： > > Draft release notes: https://github.com/apache/calcite/pull/3103 > > On Thu, Mar 9, 2023 at 11:06 PM Charles Givre wrote: > >> +1. Thank you very much for doing this! >> -- C >> >> >> >> >>> On Mar 9, 2023, at 5:01 PM, Francis Chuang >> wrote: >>> >>> +1 Thanks for being RM, Stamatis! >>> >>> On 10/03/2023 8:57 am, Stamatis Zampetakis wrote: Hello, It's been a bit more than a month since our last release [1] and there >> are currently ~30 new commits in master. Although we could wait a bit longer before cutting a new release, it >> would be nice to facilitate Drills efforts [2] in upgrading to the latest >> Calcite release by providing a version with the fix for the small breaking >> change reported under CALCITE-5522. If there are no objections, I will create an RC in the following days. If there are other must fix for 1.34.0 please let us know so that we can plan accordingly. Best, Stamatis [1] https://calcite.apache.org/docs/history.html#v1-33-0 [2] https://lists.apache.org/thread/yo4075khphgbw1dzzo6w4kpvyl7280x9 >> >>
Re: [DISCUSS] Towards Calcite 1.34.0
+1, Thanks Stamatis for driving this. Stamatis Zampetakis 于2023年3月10日周五 07:18写道： > Draft release notes: https://github.com/apache/calcite/pull/3103 > > On Thu, Mar 9, 2023 at 11:06 PM Charles Givre wrote: > > > +1. Thank you very much for doing this! > > -- C > > > > > > > > > > > On Mar 9, 2023, at 5:01 PM, Francis Chuang > > wrote: > > > > > > +1 Thanks for being RM, Stamatis! > > > > > > On 10/03/2023 8:57 am, Stamatis Zampetakis wrote: > > >> Hello, > > >> It's been a bit more than a month since our last release [1] and there > > are > > >> currently ~30 new commits in master. > > >> Although we could wait a bit longer before cutting a new release, it > > would > > >> be nice to facilitate Drills efforts [2] in upgrading to the latest > > Calcite > > >> release by providing a version with the fix for the small breaking > > change > > >> reported under CALCITE-5522. > > >> If there are no objections, I will create an RC in the following days. > > >> If there are other must fix for 1.34.0 please let us know so that we > can > > >> plan accordingly. > > >> Best, > > >> Stamatis > > >> [1] https://calcite.apache.org/docs/history.html#v1-33-0 > > >> [2] https://lists.apache.org/thread/yo4075khphgbw1dzzo6w4kpvyl7280x9 > > > > > -- Best, Benchao Li
Re: [DISCUSS] Towards Calcite 1.34.0
Draft release notes: https://github.com/apache/calcite/pull/3103 On Thu, Mar 9, 2023 at 11:06 PM Charles Givre wrote: > +1. Thank you very much for doing this! > -- C > > > > > > On Mar 9, 2023, at 5:01 PM, Francis Chuang > wrote: > > > > +1 Thanks for being RM, Stamatis! > > > > On 10/03/2023 8:57 am, Stamatis Zampetakis wrote: > >> Hello, > >> It's been a bit more than a month since our last release [1] and there > are > >> currently ~30 new commits in master. > >> Although we could wait a bit longer before cutting a new release, it > would > >> be nice to facilitate Drills efforts [2] in upgrading to the latest > Calcite > >> release by providing a version with the fix for the small breaking > change > >> reported under CALCITE-5522. > >> If there are no objections, I will create an RC in the following days. > >> If there are other must fix for 1.34.0 please let us know so that we can > >> plan accordingly. > >> Best, > >> Stamatis > >> [1] https://calcite.apache.org/docs/history.html#v1-33-0 > >> [2] https://lists.apache.org/thread/yo4075khphgbw1dzzo6w4kpvyl7280x9 > >
Re: [DISCUSS] Towards Calcite 1.34.0
+1. Thank you very much for doing this! -- C > On Mar 9, 2023, at 5:01 PM, Francis Chuang wrote: > > +1 Thanks for being RM, Stamatis! > > On 10/03/2023 8:57 am, Stamatis Zampetakis wrote: >> Hello, >> It's been a bit more than a month since our last release [1] and there are >> currently ~30 new commits in master. >> Although we could wait a bit longer before cutting a new release, it would >> be nice to facilitate Drills efforts [2] in upgrading to the latest Calcite >> release by providing a version with the fix for the small breaking change >> reported under CALCITE-5522. >> If there are no objections, I will create an RC in the following days. >> If there are other must fix for 1.34.0 please let us know so that we can >> plan accordingly. >> Best, >> Stamatis >> [1] https://calcite.apache.org/docs/history.html#v1-33-0 >> [2] https://lists.apache.org/thread/yo4075khphgbw1dzzo6w4kpvyl7280x9
Re: [DISCUSS] Towards Calcite 1.34.0
+1 Thanks for being RM, Stamatis! On 10/03/2023 8:57 am, Stamatis Zampetakis wrote: Hello, It's been a bit more than a month since our last release [1] and there are currently ~30 new commits in master. Although we could wait a bit longer before cutting a new release, it would be nice to facilitate Drills efforts [2] in upgrading to the latest Calcite release by providing a version with the fix for the small breaking change reported under CALCITE-5522. If there are no objections, I will create an RC in the following days. If there are other must fix for 1.34.0 please let us know so that we can plan accordingly. Best, Stamatis [1] https://calcite.apache.org/docs/history.html#v1-33-0 [2] https://lists.apache.org/thread/yo4075khphgbw1dzzo6w4kpvyl7280x9
[DISCUSS] Towards Calcite 1.34.0
Hello, It's been a bit more than a month since our last release [1] and there are currently ~30 new commits in master. Although we could wait a bit longer before cutting a new release, it would be nice to facilitate Drills efforts [2] in upgrading to the latest Calcite release by providing a version with the fix for the small breaking change reported under CALCITE-5522. If there are no objections, I will create an RC in the following days. If there are other must fix for 1.34.0 please let us know so that we can plan accordingly. Best, Stamatis [1] https://calcite.apache.org/docs/history.html#v1-33-0 [2] https://lists.apache.org/thread/yo4075khphgbw1dzzo6w4kpvyl7280x9
[jira] [Created] (CALCITE-5572) Release Calcite 1.34.0
Stamatis Zampetakis created CALCITE-5572: Summary: Release Calcite 1.34.0 Key: CALCITE-5572 URL: https://issues.apache.org/jira/browse/CALCITE-5572 Project: Calcite Issue Type: Task Reporter: Stamatis Zampetakis Assignee: Stamatis Zampetakis -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-5571) Remove org.jetbrains.annotations from java source code
Stamatis Zampetakis created CALCITE-5571:
Summary: Remove org.jetbrains.annotations from java source code
Key: CALCITE-5571
URL: https://issues.apache.org/jira/browse/CALCITE-5571
Project: Calcite
Issue Type: Task
Affects Versions: 1.33.0
Reporter: Stamatis Zampetakis
Assignee: Stamatis Zampetakis
In the most part we are using checkerframework annotations
(org.checkerframework.checker.nullness.qual) for specifying nullability. There
are 2 places, namely {{ScannableTableTest}} and {{UtilTest}} where we have
nullability annotations from org.jetbrains.annotations package.
To keep things consistent and also avoid mixing up annotations from different
providers in the future, I propose to remove the last references to
org.jetbrains.annotations and exclude the org.jetbrains:annotations dependency
from the build to avoid accidentally using such annotations in the future.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [QUESTION]: Bug Fix Release
Thanks Julian, I'll definitely discuss this with the others. I wonder if some cases, such as Drill's DATE_DIFF which looks a little quirky and incompatible at this point, may not merit a promotion to being tested upstream. That is, if Drill wants to have an unusual DATE_DIFF then it must expect to maintain and test it itself. On the other hand, perhaps (extending the opening lines of your email) "quirky and incompatible" is all that has ever been on offer when it comes to SQL function libraries. No lingua franca, just so many pidgins... On 2023/03/09 12:16, Julian Hyde wrote: James, As we have both discovered, the function sets of other DBMSs are confusing and often contradictory. In some cases, DBMS vendors add functions for compatibility with other DBMSs, we attempt to emulate those clones, and discover differences with the originals. In the past few weeks, Tanner, Oliver and I have done our best to add a few functions based on BigQuery's specifications without breaking compatibility (or conflicting with functions that have been added to Drill but not upstreamed). But we will have inevitably made a few mistakes. The only way I know to inoculate against this kind of problem in future is for projects like Drill to upstream tests. Julian On Wed, Mar 8, 2023 at 8:26 PM James Turton wrote: Much appreciated. I only have so much know-how in this area but CALCITE-5469 looks completely normal to me, just something that we need to accommodate due to Drill having at some point settled on a conflicting definition of DATE_DIFF that seems to resemble Hive and MySQL's DATEDIFFs (no underscore) more than anything else. We'll start a new thread if we can't simply take care of it ourselves. On 2023/03/08 19:28, Tanner Clary wrote: Hello, With regards to the unrelated issue with DATE_DIFF, I authored CALCITE-5469 so perhaps if you want to open a new thread or post a comment on the case itself, I would be happy to take a look. Best, Tanner On Wed, Mar 8, 2023 at 8:42 AM James Turton wrote: Hi All of Drill's DATE_TRUNC unit tests pass when Drill uses calcite-1.34.0-SNAPSHOT (and once we accommodate the new QUALIFY clause). While we do now have an unrelated issue with DATE_DIFF which I believe has resulted from the introduction of a three parameter DATE_DIFF function in CALCITE-5469, I'm quite sure that we can resolve this in Drill. In summary I'm a +1 for this Calcite snapshot becoming an RC. Thanks James Turton On 2023/03/07 00:11, Stamatis Zampetakis wrote: Hey Charles, Please test Drill with the latest calcite-1.34.0-SNAPSHOT [1] and if all is good on your end I will prepare an RC for vote. Best, Stamatis [1] https://repository.apache.org/content/groups/snapshots/org/apache/calcite/calcite-core/1.34.0-SNAPSHOT/ On Sun, Mar 5, 2023 at 7:16 PM Charles Givre wrote: Julian, Now that Drill is on main Calcite instead of the fork, I'll commit that the Drill community will do our best to try Drill with the RC candidates to see if we can catch issues during the release cycle. Thanks, -- C On Mar 5, 2023, at 12:20 PM, Julian Hyde wrote: It was indeed a regression, but it didn’t break any of Calcite’s tests and no one spoke up during the release vote. Mistakes are expensive to fix after a release, cheaper during the release vote, and cheapest of all if found by the test suite. On Mar 5, 2023, at 6:33 AM, Charles Givre wrote: That would be great! Again I’m only asking because this was a regression. I really do appreciate it. Thanks! Sent from my iPhone On Mar 4, 2023, at 13:59, Stamatis Zampetakis wrote: If we get the 1.34.0 out a bit sooner than usual I guess this will be good enough for Drill. If the others agree I can try to prepare an RC during next week. WDYT ? Best, Stamatis On Sat, Mar 4, 2023, 6:13 PM Alessandro Solimando < alessandro.solima...@gmail.com> wrote: The second option Benchao mentions is what Hive currently does as well. Best regards, Alessandro On Sat 4 Mar 2023, 13:19 Benchao Li, wrote: Hi Charles, Thank for reaching out! IIRC, the idea of releasing bugfix version has been brought up in the past, but I couldn't find the discussion (in Jira and dev ML). I'd like to share my understanding why we chose not to release bug fix versions, please correct me if I'm wrong, - Calcite has many bug fixes that span multi versions (even more that 10 versions), then only keeping several (such as 3) bug fix releases does not solve all these problems. - Actually we usually do not distinguish too much between "bugfix" and "new feature", so maintaining bug fix releases is not that easy. - Calcite lacks reviewers and also release managers, only keeping linear releasing in rhythm could save us some efforts. For regressions, I agree that this hurts downstream projects. For such cases, there are two approaches come into my mind: - We can release a new version quickly than usual. - The projects that need the fix/feature before
[jira] [Created] (CALCITE-5570) Support nested map type for SqlDataTypeSpec
Sergey Nuyanzin created CALCITE-5570:
Summary: Support nested map type for SqlDataTypeSpec
Key: CALCITE-5570
URL: https://issues.apache.org/jira/browse/CALCITE-5570
Project: Calcite
Issue Type: Improvement
Components: core
Reporter: Sergey Nuyanzin
There was added a similar support for arrays/multisets at
https://issues.apache.org/jira/browse/CALCITE-3250
however there is no support for maps so far.
The issue is to add such support.
I think I'd like to clarify is syntax for maps since it has 2 internal subtypes
for keys and values may be something similar to ROW with delimiter like
{code:sql}
SELECT CAST(NULL AS MAP(INT, INT));
-- or with square brackets similar to map constructor
SELECT CAST(NULL AS MAP[INT, INT]);
-- or with angle (Flink syntax)
SELECT CAST(NULL AS MAP);
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [QUESTION]: Bug Fix Release
James, As we have both discovered, the function sets of other DBMSs are confusing and often contradictory. In some cases, DBMS vendors add functions for compatibility with other DBMSs, we attempt to emulate those clones, and discover differences with the originals. In the past few weeks, Tanner, Oliver and I have done our best to add a few functions based on BigQuery's specifications without breaking compatibility (or conflicting with functions that have been added to Drill but not upstreamed). But we will have inevitably made a few mistakes. The only way I know to inoculate against this kind of problem in future is for projects like Drill to upstream tests. Julian On Wed, Mar 8, 2023 at 8:26 PM James Turton wrote: > > Much appreciated. I only have so much know-how in this area but > CALCITE-5469 looks completely normal to me, just something that we need > to accommodate due to Drill having at some point settled on a > conflicting definition of DATE_DIFF that seems to resemble Hive and > MySQL's DATEDIFFs (no underscore) more than anything else. > > We'll start a new thread if we can't simply take care of it ourselves. > > On 2023/03/08 19:28, Tanner Clary wrote: > > Hello, > > > > With regards to the unrelated issue with DATE_DIFF, I authored CALCITE-5469 > > so perhaps if you want to open a new thread or post a comment on the case > > itself, I would be happy to take a look. > > > > Best, > > Tanner > > > > On Wed, Mar 8, 2023 at 8:42 AM James Turton wrote: > > > >> Hi > >> > >> All of Drill's DATE_TRUNC unit tests pass when Drill uses > >> calcite-1.34.0-SNAPSHOT (and once we accommodate the new QUALIFY > >> clause). While we do now have an unrelated issue with DATE_DIFF which I > >> believe has resulted from the introduction of a three parameter > >> DATE_DIFF function in CALCITE-5469, I'm quite sure that we can resolve > >> this in Drill. > >> > >> In summary I'm a +1 for this Calcite snapshot becoming an RC. > >> > >> Thanks > >> James Turton > >> > >> > >> On 2023/03/07 00:11, Stamatis Zampetakis wrote: > >>> Hey Charles, > >>> > >>> Please test Drill with the latest calcite-1.34.0-SNAPSHOT [1] and if all > >> is > >>> good on your end I will prepare an RC for vote. > >>> > >>> Best, > >>> Stamatis > >>> > >>> [1] > >>> > >> https://repository.apache.org/content/groups/snapshots/org/apache/calcite/calcite-core/1.34.0-SNAPSHOT/ > >>> On Sun, Mar 5, 2023 at 7:16 PM Charles Givre wrote: > >>> > Julian, > Now that Drill is on main Calcite instead of the fork, I'll commit that > the Drill community will do our best to try Drill with the RC > >> candidates to > see if we can catch issues during the release cycle. > Thanks, > -- C > > > > On Mar 5, 2023, at 12:20 PM, Julian Hyde > >> wrote: > > It was indeed a regression, but it didn’t break any of Calcite’s tests > and no one spoke up during the release vote. Mistakes are expensive to > >> fix > after a release, cheaper during the release vote, and cheapest of all if > found by the test suite. > >> On Mar 5, 2023, at 6:33 AM, Charles Givre wrote: > >> > >> That would be great! Again I’m only asking because this was a > regression. I really do appreciate it. Thanks! > >> Sent from my iPhone > >> > >>> On Mar 4, 2023, at 13:59, Stamatis Zampetakis > wrote: > >>> If we get the 1.34.0 out a bit sooner than usual I guess this will > >> be > good > >>> enough for Drill. If the others agree I can try to prepare an RC > >> during > >>> next week. WDYT ? > >>> > >>> Best, > >>> Stamatis > >>> > >>> > On Sat, Mar 4, 2023, 6:13 PM Alessandro Solimando < > alessandro.solima...@gmail.com> wrote: > > The second option Benchao mentions is what Hive currently does as > well. > Best regards, > Alessandro > > >> On Sat 4 Mar 2023, 13:19 Benchao Li, > >> wrote: > >> Hi Charles, > >> > >> Thank for reaching out! > >> > >> IIRC, the idea of releasing bugfix version has been brought up in > the > past, > > but I couldn't find the discussion (in Jira and dev ML). > > > > I'd like to share my understanding why we chose not to release bug > fix > > versions, please correct me if I'm wrong, > > - Calcite has many bug fixes that span multi versions (even more > that 10 > > versions), then only keeping several (such as 3) bug fix releases > does > not > > solve all these problems. > > - Actually we usually do not distinguish too much between "bugfix" > and > "new > > feature", so maintaining bug fix releases is not that easy. > > - Calcite lacks reviewers and also release managers, only keeping > linear > > releasing in rhythm could save us some efforts. > > >
[jira] [Created] (CALCITE-5569) Functions with 'SPECIAL' SqlSyntax could not be created in SqlLibraryOperators
Zou created CALCITE-5569:
Summary: Functions with 'SPECIAL' SqlSyntax could not be created
in SqlLibraryOperators
Key: CALCITE-5569
URL: https://issues.apache.org/jira/browse/CALCITE-5569
Project: Calcite
Issue Type: Bug
Reporter: Zou
I want to add a function with 'SPECIAL' SqlSyntax in SqlLibraryOperators, but
I get a function not found exception
{code:java}
org.apache.calcite.runtime.CalciteContextException: From line 1, column 9 to
line 1, column 35: No match found for function signature TRY_CAST(,
)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at
org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:505)
at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:945)
at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:930)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:5464)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.handleUnresolvedFunction(SqlValidatorImpl.java:1983)
at org.apache.calcite.sql.SqlFunction.deriveType(SqlFunction.java:329)
at org.apache.calcite.sql.SqlFunction.deriveType(SqlFunction.java:231)
at
org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:6521)
at
org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:6508)
at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:161)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.deriveTypeImpl(SqlValidatorImpl.java:1897)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.deriveType(SqlValidatorImpl.java:1882)
at org.apache.calcite.sql.SqlNode.validateExpr(SqlNode.java:276)
at org.apache.calcite.sql.SqlOperator.validateCall(SqlOperator.java:474)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateCall(SqlValidatorImpl.java:6171)
at org.apache.calcite.sql.SqlCall.validate(SqlCall.java:138)
at org.apache.calcite.sql.SqlNode.validateExpr(SqlNode.java:275)
at org.apache.calcite.sql.SqlOperator.validateCall(SqlOperator.java:474)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateCall(SqlValidatorImpl.java:6171)
at org.apache.calcite.sql.SqlCall.validate(SqlCall.java:138)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:1081)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validate(SqlValidatorImpl.java:787)
at
org.apache.calcite.sql.test.AbstractSqlTester.parseAndValidate(AbstractSqlTester.java:160)
at
org.apache.calcite.sql.test.AbstractSqlTester.validateAndApply(AbstractSqlTester.java:256)
at
org.apache.calcite.sql.test.AbstractSqlTester.getColumnType(AbstractSqlTester.java:134)
at
org.apache.calcite.sql.test.AbstractSqlTester.check(AbstractSqlTester.java:234)
at
org.apache.calcite.test.SqlOperatorTest$TesterImpl.check(SqlOperatorTest.java:10091)
at org.apache.calcite.sql.test.SqlTester.check(SqlTester.java:159)
at
org.apache.calcite.test.SqlOperatorFixtureImpl.lambda$checkScalarExact$3(SqlOperatorFixtureImpl.java:232)
at
org.apache.calcite.sql.test.AbstractSqlTester.forEachQuery(AbstractSqlTester.java:444)
at
org.apache.calcite.test.SqlOperatorFixtureImpl.checkScalarExact(SqlOperatorFixtureImpl.java:231)
at
org.apache.calcite.sql.test.SqlOperatorFixture.checkScalarExact(SqlOperatorFixture.java:275)
at
org.apache.calcite.test.CalciteSqlOperatorTest.testTryCastToInt(CalciteSqlOperatorTest.java:39)
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
