[jira] [Commented] (CALCITE-6248) Illegal dates are accepted by casts
[
https://issues.apache.org/jira/browse/CALCITE-6248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817552#comment-17817552
]
Julian Hyde commented on CALCITE-6248:
--
I understand your chain of reasoning. But it is flawed, because there is an
implicit assumption that the code in Avatica is the correct implementation of
Calcite's requirements. The requirement is that {{cast('1945-02-32' as date)}}
should throw and that {{cast('1945-2-2' as date)}} should not. The ideal
pattern is thorough unit tests + a cursory system test to check assumptions.
> Illegal dates are accepted by casts
> ---
>
> Key: CALCITE-6248
> URL: https://issues.apache.org/jira/browse/CALCITE-6248
> Project: Calcite
> Issue Type: Bug
> Components: avatica, core
>Affects Versions: 1.36.0
>Reporter: Mihai Budiu
>Priority: Minor
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The following test passes in SqlOperatorTest:
> {code:java}
> @Test public void testIllegalDate() {
> final SqlOperatorFixture f = fixture();
> f.checkScalar("cast('1945-02-32' as DATE)",
> "1945-03-04", "DATE NOT NULL");
> }
> {code}
> There is no February 32, I suspect that this expression should produce an
> error.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6263) Discuss the coupling of Calcite with JTS
[
https://issues.apache.org/jira/browse/CALCITE-6263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817551#comment-17817551
]
Julian Hyde commented on CALCITE-6263:
--
I don't mind Calcite having *some* coupling to JTS, but there shouldn't be too
much. An increase of coupling happens gradually, and in this case, I was
alerted by the fact that an import was added to {{class
RelDataTypeFactoryImpl}}, a key Calcite class.
There is a good argument (I don't recall whether a Jira case was logged) that
the geospatial functions should be in a separate module, and should be
available only when that module is on the class path and {{fun=spatial}} is on
the connect string. Not because we don't like spatial functions, but because
some people want to embed a more minimal Calcite.
In that scenario, should there be a built-in {{GEOMETRY}} type? I think yes.
But would you be able to do anything with values of type {{GEOMETRY}}? No, not
much, besides test whether they are null, because the core module would not
include JTS.
This may seem like Solomon cutting the baby in half just to prove a point. But
there is value in Calcite being able to parse, prepare and plan a query that it
cannot optimize.
There is a reasonable scenario where {{GEOMETRY}} values are represented as WKT
strings, enter from a JDBC source as WKT strings, and leave as WKT strings. In
a pass-through scenario like the one that motived CALCITE-6239, converting the
{{GEOMETRY}} values to JTS objects and then converting them back to strings is
actually less efficient. What if WKT were the default format for {{GEOMETRY}}
values?
This would not be the first time that Calcite has chosen the efficient
representation. ('Efficient' here meaning using very little memory, and
minimizing the CPU cost of deserializing values from the producer and
serializing values to the consumer.) In enumerable convention, {{DATE}} values
are represented as Java {{int}} values (or {{java.lang.Integer}} values if
nullable) rather than {{java.sql.Date}}.
If we did that, then the {{clazz}} field in {{RelDataTypeFactoryImpl.JavaType}}
would hold the value {{String.class}} not {{Geometry.class}}.
> Discuss the coupling of Calcite with JTS
>
>
> Key: CALCITE-6263
> URL: https://issues.apache.org/jira/browse/CALCITE-6263
> Project: Calcite
> Issue Type: New Feature
> Components: jdbc-adapter
>Reporter: Bertil Chapuis
>Priority: Major
>
> In order to push ST functions down to Postgis in the JDBC adapter, it is
> necessary to register a type family for geometries in
> [RelDataTypeFactoryImpl.java|https://github.com/apache/calcite/pull/3668/files#diff-0fa7bd8b0354c8a4c331efa4107242e49c5d521f31adbb71388bcbc9acb7a384].
> This changes increases the coupling of Calcite to a geometry library such as
> JTS.
> As this is an architectural change, a few options can be considered:
> # Accepting the coupling of Calcite with JTS.
> # Introducing an abstraction for geometry libraries in Calcite.
> # Using reflection to register the type family only if JTS is available in
> the classpath.
> Personally, I have a preference for options 1 and 3. Option 3, which is
> currently implemented in
> [CALCITE-6239|https://github.com/apache/calcite/pull/3668] has little impact
> on the current behavior. Option 2 would introduce some additional complexity.
> For context, here is a
> [link|https://github.com/apache/calcite/pull/3668#discussion_r1486925458] to
> the original discussion.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6265) Cannot provide different numeric type as placeholder
[
https://issues.apache.org/jira/browse/CALCITE-6265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817548#comment-17817548
]
Julian Hyde commented on CALCITE-6265:
--
I think the bug is in Avatica - or at any rate, Avatica is the most logical
place to fix it. If a parameter has type {{{}INTEGER{}}}, and a user calls
{{{}PreparedStatement.setShort{}}}, it is Avatica's job to coerce that value to
a {{{}java.lang.Integer{}}}.
It is analogous to – in fact, the reverse of – when someone calls
{{ResultSet.getInt}} on a column that is of type {{{}SMALLINT{}}}. I believe
that Avatica does that conversion already.
> Cannot provide different numeric type as placeholder
>
>
> Key: CALCITE-6265
> URL: https://issues.apache.org/jira/browse/CALCITE-6265
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Tim Nieradzik
>Assignee: Tim Nieradzik
>Priority: Major
> Labels: pull-request-available
>
> The _empid_ column is of type {_}INT{_}. When providing a _short_ value as a
> placeholder, a _ClassCastException_ is thrown.
> *Test case:*
> {{ final String sql =}}
> {{ "select \"empid\" from \"hr\".\"emps\" where \"empid\" in (?,
> ?)";}}{{ CalciteAssert.hr()}}
> {{ .query(sql)}}
> {{ .consumesPreparedStatement(p -> {}}
> {{ p.setShort(1, (short) 100);}}
> {{ p.setShort(2, (short) 110);}}
> {{ })}}
> {{ .returnsUnordered("empid=100", "empid=110");}}
> *Stack trace:*
> {{java.lang.ClassCastException: class java.lang.Short cannot be cast to class
> java.lang.Integer (java.lang.Short and java.lang.Integer are in module
> java.base of loader 'bootstrap')}}
> {{ at Baz$1$1.moveNext(Unknown Source)}}
> {{ at
> org.apache.calcite.linq4j.Linq4j$EnumeratorIterator.(Linq4j.java:679)}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6265) Cannot provide different numeric type as placeholder
[
https://issues.apache.org/jira/browse/CALCITE-6265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817547#comment-17817547
]
Alessandro Solimando commented on CALCITE-6265:
---
[~tnieradzik] I think it's worth mentioning in the ticket title that we are
dealing with a prepared statement, I didn't get what placeholder meant until I
saw the example, in the release notes we don't have them so it's better to
improve the title too.
> Cannot provide different numeric type as placeholder
>
>
> Key: CALCITE-6265
> URL: https://issues.apache.org/jira/browse/CALCITE-6265
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Tim Nieradzik
>Assignee: Tim Nieradzik
>Priority: Major
> Labels: pull-request-available
>
> The _empid_ column is of type {_}INT{_}. When providing a _short_ value as a
> placeholder, a _ClassCastException_ is thrown.
> *Test case:*
> {{ final String sql =}}
> {{ "select \"empid\" from \"hr\".\"emps\" where \"empid\" in (?,
> ?)";}}{{ CalciteAssert.hr()}}
> {{ .query(sql)}}
> {{ .consumesPreparedStatement(p -> {}}
> {{ p.setShort(1, (short) 100);}}
> {{ p.setShort(2, (short) 110);}}
> {{ })}}
> {{ .returnsUnordered("empid=100", "empid=110");}}
> *Stack trace:*
> {{java.lang.ClassCastException: class java.lang.Short cannot be cast to class
> java.lang.Integer (java.lang.Short and java.lang.Integer are in module
> java.base of loader 'bootstrap')}}
> {{ at Baz$1$1.moveNext(Unknown Source)}}
> {{ at
> org.apache.calcite.linq4j.Linq4j$EnumeratorIterator.(Linq4j.java:679)}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6248) Illegal dates are accepted by casts
[
https://issues.apache.org/jira/browse/CALCITE-6248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817545#comment-17817545
]
Mihai Budiu commented on CALCITE-6248:
--
The validation code is in Avatica, so the tests are there.
But it looks like the validation code that is applied to literals should not be
applied the strings that appear in casts.
> Illegal dates are accepted by casts
> ---
>
> Key: CALCITE-6248
> URL: https://issues.apache.org/jira/browse/CALCITE-6248
> Project: Calcite
> Issue Type: Bug
> Components: avatica, core
>Affects Versions: 1.36.0
>Reporter: Mihai Budiu
>Priority: Minor
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The following test passes in SqlOperatorTest:
> {code:java}
> @Test public void testIllegalDate() {
> final SqlOperatorFixture f = fixture();
> f.checkScalar("cast('1945-02-32' as DATE)",
> "1945-03-04", "DATE NOT NULL");
> }
> {code}
> There is no February 32, I suspect that this expression should produce an
> error.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6248) Illegal dates are accepted by casts
[
https://issues.apache.org/jira/browse/CALCITE-6248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817544#comment-17817544
]
Julian Hyde commented on CALCITE-6248:
--
I think we should remain reasonably liberal in the format we accept. Parsing a
string into year / month / date fields is one thing, and verifying whether
those fields represent a valid ISO 8601 date is another. This case is just
about the latter question.
Reviewing the above commit, I was surprised that there were no tests that
{{cast('1945-02-32' as DATE)}} gives an error (at validate time or run time)
and that {{select cast(d as date) from (values '1945-02-32') as t (d)}} gives
an error at run time.
> Illegal dates are accepted by casts
> ---
>
> Key: CALCITE-6248
> URL: https://issues.apache.org/jira/browse/CALCITE-6248
> Project: Calcite
> Issue Type: Bug
> Components: avatica, core
>Affects Versions: 1.36.0
>Reporter: Mihai Budiu
>Priority: Minor
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The following test passes in SqlOperatorTest:
> {code:java}
> @Test public void testIllegalDate() {
> final SqlOperatorFixture f = fixture();
> f.checkScalar("cast('1945-02-32' as DATE)",
> "1945-03-04", "DATE NOT NULL");
> }
> {code}
> There is no February 32, I suspect that this expression should produce an
> error.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6261) RelBuilder.aggregate() field pruning does not use permuted field indices when used with force project and duplicate agg calls
[
https://issues.apache.org/jira/browse/CALCITE-6261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817542#comment-17817542
]
Julian Hyde commented on CALCITE-6261:
--
[~zrlpar], No hurry. I know how corporate lawyers can be. (The second
contribution should be much easier than the first!) Send the PR whenever it's
ready, and nudge me if I don't review it in a timely manner.
One easy (and easily maintainable) way to add tests is in Quidem tests such as
{{agg.iq}}. Assuming that this bug reproduces via the SQL interface, I would
add a minimal test in {{RelBuilderTest}} and add one or two queries to
{{agg.iq}} to increase the coverage.
> RelBuilder.aggregate() field pruning does not use permuted field indices when
> used with force project and duplicate agg calls
> -
>
> Key: CALCITE-6261
> URL: https://issues.apache.org/jira/browse/CALCITE-6261
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0, 1.36.0
>Reporter: Niels Pardon
>Assignee: Niels Pardon
>Priority: Major
> Fix For: 1.37.0
>
>
> We were running into issues with RelBuilder.aggregate() when we tried to
> upgrade our code from Calcite 1.32.0 to 1.36.0 and after some debugging it
> seems this is caused by changes introduced with CALCITE-4334.
> I was able to put together this test case for RelBuilderTest reproducing the
> issue:
> {code:java}
> @Test void testAggregateForceProject() {
> final Function f1 = builder ->
> builder.scan("EMP")
> .project(
> ImmutableList.of(
> builder.field("EMPNO"),
> builder.field("ENAME"),
> builder.field("JOB"),
> builder.field("MGR"),
> builder.field("HIREDATE"),
> builder.field("SAL"),
> builder.field("COMM"),
> builder.field("DEPTNO")),
> ImmutableList.of(),
> true);
> final Function f2 = builder ->
> builder.aggregate(
> builder.groupKey(builder.field("MGR")),
> builder.avg(false, "SALARY_AVG", builder.field("SAL")),
> builder.sum(false, "SALARY_SUM", builder.field("SAL")),
> builder.avg(false, "SALARY_MEAN", builder.field("SAL")));
> final String expected = ""
> + "LogicalProject(MGR=[$0], SALARY_AVG=[$1], SALARY_SUM=[$2],
> SALARY_MEAN=[$1])\n"
> + " LogicalAggregate(group=[{0}], SALARY_AVG=[AVG($1)],
> SALARY_SUM=[SUM($1)])\n"
> + "LogicalProject(MGR=[$3], SAL=[$5])\n"
> + " LogicalTableScan(table=[[scott, EMP]])\n";
> assertThat(f2.apply(f1.apply(createBuilder())).build(), hasTree(expected));
> } {code}
> With Calcite 1.36.0 you will get an AssertionError:
> {code:java}
> java.lang.AssertionError
> at org.apache.calcite.rel.core.Aggregate.(Aggregate.java:175)
> at
> org.apache.calcite.rel.logical.LogicalAggregate.(LogicalAggregate.java:72)
> at
> org.apache.calcite.rel.logical.LogicalAggregate.create_(LogicalAggregate.java:144)
> at
> org.apache.calcite.rel.logical.LogicalAggregate.create(LogicalAggregate.java:116)
> at
> org.apache.calcite.rel.core.RelFactories$AggregateFactoryImpl.createAggregate(RelFactories.java:333)
> at org.apache.calcite.tools.RelBuilder.aggregate_(RelBuilder.java:2576)
> at org.apache.calcite.tools.RelBuilder.aggregate_(RelBuilder.java:2523)
> at org.apache.calcite.tools.RelBuilder.aggregate(RelBuilder.java:2335)
> at
> org.apache.calcite.test.RelBuilderTest.lambda$testAggregateForceProject$36(RelBuilderTest.java:1509)
> at
> org.apache.calcite.test.RelBuilderTest.testAggregateForceProject(RelBuilderTest.java:1522)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
> at
> org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
> at
> org.junit.jupiter.engine.extension.SameThreadTimeoutInvocation.proceed(SameThreadTimeoutInvocation.java:45)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156)
> at
>
[jira] [Assigned] (CALCITE-3312) TIMESTAMPDIFF cannot be converted to SQL
[
https://issues.apache.org/jira/browse/CALCITE-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
TJ Banghart reassigned CALCITE-3312:
Assignee: (was: TJ Banghart)
> TIMESTAMPDIFF cannot be converted to SQL
>
>
> Key: CALCITE-3312
> URL: https://issues.apache.org/jira/browse/CALCITE-3312
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Pavel Gubin
>Priority: Major
>
> The following test in {{RelToSqlConverterTest}}:
> {code}
> @Test public void testTimestampDiff() {
> String query = "SELECT {fn TIMESTAMPDIFF(SQL_TSI_YEAR,TIMESTAMP
> '2016-01-01 00:00:00', TIMESTAMP '2017-01-01 00:00:00')}";
> String expected = "";
> sql(query).ok(expected);
> }
> {code}
> fails with:
> {noformat}
> java.lang.UnsupportedOperationException: class
> org.apache.calcite.sql.SqlSyntax$6: SPECIAL
> at org.apache.calcite.util.Util.needToImplement(Util.java:967)
> at org.apache.calcite.sql.SqlSyntax$6.unparse(SqlSyntax.java:116)
> at org.apache.calcite.sql.SqlOperator.unparse(SqlOperator.java:348)
> at org.apache.calcite.sql.SqlDialect.unparseCall(SqlDialect.java:402)
> at org.apache.calcite.sql.SqlCall.unparse(SqlCall.java:105)
> at org.apache.calcite.sql.SqlUtil.unparseBinarySyntax(SqlUtil.java:382)
> at org.apache.calcite.sql.SqlSyntax$3.unparse(SqlSyntax.java:65)
> at org.apache.calcite.sql.SqlOperator.unparse(SqlOperator.java:348)
> at org.apache.calcite.sql.SqlDialect.unparseCall(SqlDialect.java:402)
> at org.apache.calcite.sql.SqlCall.unparse(SqlCall.java:108)
> at
> org.apache.calcite.sql.fun.SqlCastFunction.unparse(SqlCastFunction.java:174)
> at org.apache.calcite.sql.SqlDialect.unparseCall(SqlDialect.java:402)
> at org.apache.calcite.sql.SqlCall.unparse(SqlCall.java:108)
> at org.apache.calcite.sql.SqlNodeList.commaList(SqlNodeList.java:121)
> at
> org.apache.calcite.sql.SqlOperator.unparseListClause(SqlOperator.java:365)
> at
> org.apache.calcite.sql.SqlOperator.unparseListClause(SqlOperator.java:354)
> at
> org.apache.calcite.sql.SqlSelectOperator.unparse(SqlSelectOperator.java:152)
> at org.apache.calcite.sql.SqlDialect.unparseCall(SqlDialect.java:402)
> at org.apache.calcite.sql.SqlSelect.unparse(SqlSelect.java:230)
> at org.apache.calcite.sql.SqlNode.toSqlString(SqlNode.java:152)
> at org.apache.calcite.sql.SqlNode.toSqlString(SqlNode.java:157)
> at
> org.apache.calcite.rel.rel2sql.RelToSqlConverterTest.toSql(RelToSqlConverterTest.java:145)
> at
> org.apache.calcite.rel.rel2sql.RelToSqlConverterTest.access$100(RelToSqlConverterTest.java:77)
> at
> org.apache.calcite.rel.rel2sql.RelToSqlConverterTest$Sql.exec(RelToSqlConverterTest.java:3634)
> at
> org.apache.calcite.rel.rel2sql.RelToSqlConverterTest$Sql.ok(RelToSqlConverterTest.java:3609)
> at
> org.apache.calcite.rel.rel2sql.RelToSqlConverterTest.testTimestampDiff(RelToSqlConverterTest.java:1942)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
>
[jira] [Commented] (CALCITE-6248) Illegal dates are accepted by casts
[
https://issues.apache.org/jira/browse/CALCITE-6248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817527#comment-17817527
]
Mihai Budiu commented on CALCITE-6248:
--
I have a question about this Quidem test in misc.iq:
{code}
# Slightly different format
# (Incidentally, this format is not allowed in date literals, per the standard)
values cast('1989-7-4' as date);
{code}
This test explicitly assumes that casts are more liberal in the date formats
they accept than date literals. Is this true? If so, then this whole bugfix has
to be rethought. [~julianhyde] you actually wrote this test in 2016.
> Illegal dates are accepted by casts
> ---
>
> Key: CALCITE-6248
> URL: https://issues.apache.org/jira/browse/CALCITE-6248
> Project: Calcite
> Issue Type: Bug
> Components: avatica, core
>Affects Versions: 1.36.0
>Reporter: Mihai Budiu
>Priority: Minor
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The following test passes in SqlOperatorTest:
> {code:java}
> @Test public void testIllegalDate() {
> final SqlOperatorFixture f = fixture();
> f.checkScalar("cast('1945-02-32' as DATE)",
> "1945-03-04", "DATE NOT NULL");
> }
> {code}
> There is no February 32, I suspect that this expression should produce an
> error.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5886) Task :spark:testClasses unstable due to ConnectException
[
https://issues.apache.org/jira/browse/CALCITE-5886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817528#comment-17817528
]
Greg Harris commented on CALCITE-5886:
--
Hi folks, I found that this is actually a Gradle bug:
https://github.com/gradle/gradle/issues/27801
> Task :spark:testClasses unstable due to ConnectException
> -
>
> Key: CALCITE-5886
> URL: https://issues.apache.org/jira/browse/CALCITE-5886
> Project: Calcite
> Issue Type: Improvement
> Components: spark
>Affects Versions: 1.35.0
>Reporter: LakeShen
>Priority: Major
>
> After I pushed my pr,I saw the calcite CI/CD workflow has the following error:
> {code:java}
> > Task :spark:testClasses
> Unexpected exception thrown.
> org.gradle.internal.remote.internal.MessageIOException: Could not read
> message from '/127.0.0.1:60778'.
> at
> org.gradle.internal.remote.internal.inet.SocketConnection.receive(SocketConnection.java:94)
> at
> org.gradle.internal.remote.internal.hub.MessageHub$ConnectionReceive.run(MessageHub.java:270)
> at
> org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
> at
> org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:49)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.base/java.lang.Thread.run(Thread.java:833)
> Caused by: java.lang.IllegalArgumentException
> at
> org.gradle.internal.remote.internal.hub.InterHubMessageSerializer$MessageReader.read(InterHubMessageSerializer.java:72)
> at
> org.gradle.internal.remote.internal.hub.InterHubMessageSerializer$MessageReader.read(InterHubMessageSerializer.java:52)
> at
> org.gradle.internal.remote.internal.inet.SocketConnection.receive(SocketConnection.java:81)
> ... 6 more
> > Task :spark:test FAILED
> org.gradle.internal.remote.internal.ConnectException: Could not connect to
> server [8185c6ce-e464-4551-8250-0adaec77721f port:34907,
> addresses:[/127.0.0.1]]. Tried addresses: [/127.0.0.1].
> at
> org.gradle.internal.remote.internal.inet.TcpOutgoingConnector.connect(TcpOutgoingConnector.java:67)
> at
> org.gradle.internal.remote.internal.hub.MessageHubBackedClient.getConnection(MessageHubBackedClient.java:36)
> at
> org.gradle.process.internal.worker.child.SystemApplicationClassLoaderWorker.call(SystemApplicationClassLoaderWorker.java:103)
> at
> org.gradle.process.internal.worker.child.SystemApplicationClassLoaderWorker.call(SystemApplicationClassLoaderWorker.java:65)
> at
> worker.org.gradle.process.internal.worker.GradleWorkerMain.run(GradleWorkerMain.java:69)
> at
> worker.org.gradle.process.internal.worker.GradleWorkerMain.main(GradleWorkerMain.java:74)
> Caused by: java.net.ConnectException: Connection refused
> at java.base/sun.nio.ch.Net.pollConnect(Native Method)
> at java.base/sun.nio.ch.Net.pollConnectNow(Net.java:672)
> at
> java.base/sun.nio.ch.SocketChannelImpl.finishTimedConnect(SocketChannelImpl.java:1141)
> at
> java.base/sun.nio.ch.SocketChannelImpl.blockingConnect(SocketChannelImpl.java:1183)
> at java.base/sun.nio.ch.SocketAdaptor.connect(SocketAdaptor.java:98)
> at
> org.gradle.internal.remote.internal.inet.TcpOutgoingConnector.tryConnect(TcpOutgoingConnector.java:81)
> at
> org.gradle.internal.remote.internal.inet.TcpOutgoingConnector.connect(TcpOutgoingConnector.java:54)
> ... 5 more {code}
> It looks like the network issue caused this problem.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6248) Illegal dates are accepted by casts
[
https://issues.apache.org/jira/browse/CALCITE-6248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817525#comment-17817525
]
Mihai Budiu commented on CALCITE-6248:
--
I apologize, but it looks like my fix for Calcite was not sufficient, dates
with spaces are still illegal. So I will create a second PR for the same issue.
Hopefully it is the last one.
> Illegal dates are accepted by casts
> ---
>
> Key: CALCITE-6248
> URL: https://issues.apache.org/jira/browse/CALCITE-6248
> Project: Calcite
> Issue Type: Bug
> Components: avatica, core
>Affects Versions: 1.36.0
>Reporter: Mihai Budiu
>Priority: Minor
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The following test passes in SqlOperatorTest:
> {code:java}
> @Test public void testIllegalDate() {
> final SqlOperatorFixture f = fixture();
> f.checkScalar("cast('1945-02-32' as DATE)",
> "1945-03-04", "DATE NOT NULL");
> }
> {code}
> There is no February 32, I suspect that this expression should produce an
> error.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (CALCITE-4859) Tableau connector for Calcite
[ https://issues.apache.org/jira/browse/CALCITE-4859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jerin John reassigned CALCITE-4859: --- Assignee: Jerin John (was: Julian Hyde) > Tableau connector for Calcite > - > > Key: CALCITE-4859 > URL: https://issues.apache.org/jira/browse/CALCITE-4859 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Jerin John >Priority: Major > > Create a Tableau connector for Calcite. This will allow Tableau to connect to > a Calcite server via Avatica. > The format will be a directory of files, similar to [Tableau's Postgres JDBC > example|https://github.com/tableau/connector-plugin-sdk/tree/master/samples/plugins/postgres_jdbc]. > Other projects that use Calcite/Avatica will be able to fork this connector > and customize it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-6210) Cast to VARBINARY causes an assertion failure
[
https://issues.apache.org/jira/browse/CALCITE-6210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817484#comment-17817484
]
Mihai Budiu commented on CALCITE-6210:
--
Your approach seems to be the only one reasonable based on my knowledge of
Calcite's capabilities.
The principled way to solve this would be to have Calcite handle casts like
library functions, and allow them to have dialect-dependent implementations.
But I don't know whether that's possible without major surgery on the codebase.
One issue that complicates rewriting casts is the fact that Calcite often
leaves casts implicit in the code rather than inserting explicit casts. If all
casts were explicit your job would be much easier. The good news is that there
aren't many legal casts to/from BINARY values, so you have fewer cases to
consider.
> Cast to VARBINARY causes an assertion failure
> -
>
> Key: CALCITE-6210
> URL: https://issues.apache.org/jira/browse/CALCITE-6210
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Mihai Budiu
>Priority: Minor
> Labels: pull-request-available
>
> This test in SqlOperatorTest:
> {code:java}
> SqlOperatorFixture f = fixture();
> f.checkScalar("CAST('00' AS VARBINARY)", "00", "VARBINARY NOT NULL");
> {code}
> Causes the following assertion failure:
> {code}
> java.lang.AssertionError: value 00 does not match type class
> org.apache.calcite.avatica.util.ByteString
> at
> org.apache.calcite.linq4j.tree.ConstantExpression.(ConstantExpression.java:51)
> at
> org.apache.calcite.linq4j.tree.Expressions.constant(Expressions.java:585)
> at
> org.apache.calcite.linq4j.tree.OptimizeShuttle.visit(OptimizeShuttle.java:305)
> at
> org.apache.calcite.linq4j.tree.UnaryExpression.accept(UnaryExpression.java:39)
> at
> org.apache.calcite.linq4j.tree.TernaryExpression.accept(TernaryExpression.java:47)
> at
> org.apache.calcite.linq4j.tree.DeclarationStatement.accept(DeclarationStatement.java:45)
> at
> org.apache.calcite.linq4j.tree.DeclarationStatement.accept(DeclarationStatement.java:27)
> at
> org.apache.calcite.linq4j.tree.BlockBuilder.optimize(BlockBuilder.java:426)
> at
> org.apache.calcite.linq4j.tree.BlockBuilder.toBlock(BlockBuilder.java:340)
> at
> org.apache.calcite.rex.RexExecutorImpl.compile(RexExecutorImpl.java:102)
> at
> org.apache.calcite.rex.RexExecutorImpl.compile(RexExecutorImpl.java:68)
> at
> org.apache.calcite.rex.RexExecutorImpl.reduce(RexExecutorImpl.java:133)
> at
> org.apache.calcite.rex.RexSimplify.simplifyCast(RexSimplify.java:2272)
> at org.apache.calcite.rex.RexSimplify.simplify(RexSimplify.java:292)
> at
> org.apache.calcite.rex.RexSimplify.simplifyUnknownAs(RexSimplify.java:250)
> at
> org.apache.calcite.rex.RexSimplify.simplifyPreservingType(RexSimplify.java:189)
> at
> org.apache.calcite.rex.RexSimplify.simplifyPreservingType(RexSimplify.java:184)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6261) RelBuilder.aggregate() field pruning does not use permuted field indices when used with force project and duplicate agg calls
[
https://issues.apache.org/jira/browse/CALCITE-6261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817455#comment-17817455
]
Niels Pardon commented on CALCITE-6261:
---
[~pmsgd] I would use the following unit test to recreate your reproducer from
CALCITE-5888, please tell me if you think this correctly represents your issue.
It uses slightly less verbose syntax and the existing tables used in
RelBuilderTest instead of your CalciqueTable classes. Though it should be
structurally the same.
{code:java}
@Test void
testAggregateDuplicateAggCallsAndFieldPruningWithJoinAndLiteralGroupKey() {
final Function f1 = builder ->
// first inner join two tables
builder.scan("EMP").scan("DEPT")
.join(JoinRelType.INNER, "DEPTNO")
.aggregate(
// null group key
builder.groupKey(builder.cast(builder.literal(null),
SqlTypeName.INTEGER)),
// duplicated min/max agg calls
builder.min(builder.field("SAL")),
builder.max(builder.field("SAL")),
builder.min(builder.field("SAL")),
builder.max(builder.field("SAL")))
.build();
final String expected = ""
+ "LogicalProject($f11=[$0], $f1=[$1], $f2=[$2], $f10=[$1], $f20=[$2])\n"
+ " LogicalAggregate(group=[{1}], agg#0=[MIN($0)], agg#1=[MAX($0)])\n"
+ "LogicalProject(SAL=[$5], $f11=[null:INTEGER])\n"
+ " LogicalJoin(condition=[=($7, $8)], joinType=[inner])\n"
+ "LogicalTableScan(table=[[scott, EMP]])\n"
+ "LogicalTableScan(table=[[scott, DEPT]])\n";
assertThat(f1.apply(createBuilder()), hasTree(expected));
} {code}
> RelBuilder.aggregate() field pruning does not use permuted field indices when
> used with force project and duplicate agg calls
> -
>
> Key: CALCITE-6261
> URL: https://issues.apache.org/jira/browse/CALCITE-6261
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0, 1.36.0
>Reporter: Niels Pardon
>Assignee: Niels Pardon
>Priority: Major
> Fix For: 1.37.0
>
>
> We were running into issues with RelBuilder.aggregate() when we tried to
> upgrade our code from Calcite 1.32.0 to 1.36.0 and after some debugging it
> seems this is caused by changes introduced with CALCITE-4334.
> I was able to put together this test case for RelBuilderTest reproducing the
> issue:
> {code:java}
> @Test void testAggregateForceProject() {
> final Function f1 = builder ->
> builder.scan("EMP")
> .project(
> ImmutableList.of(
> builder.field("EMPNO"),
> builder.field("ENAME"),
> builder.field("JOB"),
> builder.field("MGR"),
> builder.field("HIREDATE"),
> builder.field("SAL"),
> builder.field("COMM"),
> builder.field("DEPTNO")),
> ImmutableList.of(),
> true);
> final Function f2 = builder ->
> builder.aggregate(
> builder.groupKey(builder.field("MGR")),
> builder.avg(false, "SALARY_AVG", builder.field("SAL")),
> builder.sum(false, "SALARY_SUM", builder.field("SAL")),
> builder.avg(false, "SALARY_MEAN", builder.field("SAL")));
> final String expected = ""
> + "LogicalProject(MGR=[$0], SALARY_AVG=[$1], SALARY_SUM=[$2],
> SALARY_MEAN=[$1])\n"
> + " LogicalAggregate(group=[{0}], SALARY_AVG=[AVG($1)],
> SALARY_SUM=[SUM($1)])\n"
> + "LogicalProject(MGR=[$3], SAL=[$5])\n"
> + " LogicalTableScan(table=[[scott, EMP]])\n";
> assertThat(f2.apply(f1.apply(createBuilder())).build(), hasTree(expected));
> } {code}
> With Calcite 1.36.0 you will get an AssertionError:
> {code:java}
> java.lang.AssertionError
> at org.apache.calcite.rel.core.Aggregate.(Aggregate.java:175)
> at
> org.apache.calcite.rel.logical.LogicalAggregate.(LogicalAggregate.java:72)
> at
> org.apache.calcite.rel.logical.LogicalAggregate.create_(LogicalAggregate.java:144)
> at
> org.apache.calcite.rel.logical.LogicalAggregate.create(LogicalAggregate.java:116)
> at
> org.apache.calcite.rel.core.RelFactories$AggregateFactoryImpl.createAggregate(RelFactories.java:333)
> at org.apache.calcite.tools.RelBuilder.aggregate_(RelBuilder.java:2576)
> at org.apache.calcite.tools.RelBuilder.aggregate_(RelBuilder.java:2523)
> at org.apache.calcite.tools.RelBuilder.aggregate(RelBuilder.java:2335)
> at
> org.apache.calcite.test.RelBuilderTest.lambda$testAggregateForceProject$36(RelBuilderTest.java:1509)
> at
>
[jira] [Updated] (CALCITE-6265) Cannot provide different numeric type as placeholder
[
https://issues.apache.org/jira/browse/CALCITE-6265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6265:
Labels: pull-request-available (was: )
> Cannot provide different numeric type as placeholder
>
>
> Key: CALCITE-6265
> URL: https://issues.apache.org/jira/browse/CALCITE-6265
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Tim Nieradzik
>Assignee: Tim Nieradzik
>Priority: Major
> Labels: pull-request-available
>
> The _empid_ column is of type {_}INT{_}. When providing a _short_ value as a
> placeholder, a _ClassCastException_ is thrown.
> *Test case:*
> {{ final String sql =}}
> {{ "select \"empid\" from \"hr\".\"emps\" where \"empid\" in (?,
> ?)";}}{{ CalciteAssert.hr()}}
> {{ .query(sql)}}
> {{ .consumesPreparedStatement(p -> {}}
> {{ p.setShort(1, (short) 100);}}
> {{ p.setShort(2, (short) 110);}}
> {{ })}}
> {{ .returnsUnordered("empid=100", "empid=110");}}
> *Stack trace:*
> {{java.lang.ClassCastException: class java.lang.Short cannot be cast to class
> java.lang.Integer (java.lang.Short and java.lang.Integer are in module
> java.base of loader 'bootstrap')}}
> {{ at Baz$1$1.moveNext(Unknown Source)}}
> {{ at
> org.apache.calcite.linq4j.Linq4j$EnumeratorIterator.(Linq4j.java:679)}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6261) RelBuilder.aggregate() field pruning does not use permuted field indices when used with force project and duplicate agg calls
[
https://issues.apache.org/jira/browse/CALCITE-6261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817443#comment-17817443
]
Niels Pardon commented on CALCITE-6261:
---
Would love to make it for 1.37.0. Just waiting for my employer right now so
that I can push the submit PR button :)
> RelBuilder.aggregate() field pruning does not use permuted field indices when
> used with force project and duplicate agg calls
> -
>
> Key: CALCITE-6261
> URL: https://issues.apache.org/jira/browse/CALCITE-6261
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0, 1.36.0
>Reporter: Niels Pardon
>Assignee: Niels Pardon
>Priority: Major
> Fix For: 1.37.0
>
>
> We were running into issues with RelBuilder.aggregate() when we tried to
> upgrade our code from Calcite 1.32.0 to 1.36.0 and after some debugging it
> seems this is caused by changes introduced with CALCITE-4334.
> I was able to put together this test case for RelBuilderTest reproducing the
> issue:
> {code:java}
> @Test void testAggregateForceProject() {
> final Function f1 = builder ->
> builder.scan("EMP")
> .project(
> ImmutableList.of(
> builder.field("EMPNO"),
> builder.field("ENAME"),
> builder.field("JOB"),
> builder.field("MGR"),
> builder.field("HIREDATE"),
> builder.field("SAL"),
> builder.field("COMM"),
> builder.field("DEPTNO")),
> ImmutableList.of(),
> true);
> final Function f2 = builder ->
> builder.aggregate(
> builder.groupKey(builder.field("MGR")),
> builder.avg(false, "SALARY_AVG", builder.field("SAL")),
> builder.sum(false, "SALARY_SUM", builder.field("SAL")),
> builder.avg(false, "SALARY_MEAN", builder.field("SAL")));
> final String expected = ""
> + "LogicalProject(MGR=[$0], SALARY_AVG=[$1], SALARY_SUM=[$2],
> SALARY_MEAN=[$1])\n"
> + " LogicalAggregate(group=[{0}], SALARY_AVG=[AVG($1)],
> SALARY_SUM=[SUM($1)])\n"
> + "LogicalProject(MGR=[$3], SAL=[$5])\n"
> + " LogicalTableScan(table=[[scott, EMP]])\n";
> assertThat(f2.apply(f1.apply(createBuilder())).build(), hasTree(expected));
> } {code}
> With Calcite 1.36.0 you will get an AssertionError:
> {code:java}
> java.lang.AssertionError
> at org.apache.calcite.rel.core.Aggregate.(Aggregate.java:175)
> at
> org.apache.calcite.rel.logical.LogicalAggregate.(LogicalAggregate.java:72)
> at
> org.apache.calcite.rel.logical.LogicalAggregate.create_(LogicalAggregate.java:144)
> at
> org.apache.calcite.rel.logical.LogicalAggregate.create(LogicalAggregate.java:116)
> at
> org.apache.calcite.rel.core.RelFactories$AggregateFactoryImpl.createAggregate(RelFactories.java:333)
> at org.apache.calcite.tools.RelBuilder.aggregate_(RelBuilder.java:2576)
> at org.apache.calcite.tools.RelBuilder.aggregate_(RelBuilder.java:2523)
> at org.apache.calcite.tools.RelBuilder.aggregate(RelBuilder.java:2335)
> at
> org.apache.calcite.test.RelBuilderTest.lambda$testAggregateForceProject$36(RelBuilderTest.java:1509)
> at
> org.apache.calcite.test.RelBuilderTest.testAggregateForceProject(RelBuilderTest.java:1522)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
> at
> org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
> at
> org.junit.jupiter.engine.extension.SameThreadTimeoutInvocation.proceed(SameThreadTimeoutInvocation.java:45)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103)
> at
>
[jira] [Updated] (CALCITE-6265) Cannot provide different numeric type as placeholder
[
https://issues.apache.org/jira/browse/CALCITE-6265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Nieradzik updated CALCITE-6265:
---
Description:
The _empid_ column is of type {_}INT{_}. When providing a _short_ value as a
placeholder, a _ClassCastException_ is thrown.
*Test case:*
{{ final String sql =}}
{{ "select \"empid\" from \"hr\".\"emps\" where \"empid\" in (?,
?)";}}{{ CalciteAssert.hr()}}
{{ .query(sql)}}
{{ .consumesPreparedStatement(p -> {}}
{{ p.setShort(1, (short) 100);}}
{{ p.setShort(2, (short) 110);}}
{{ })}}
{{ .returnsUnordered("empid=100", "empid=110");}}
*Stack trace:*
{{java.lang.ClassCastException: class java.lang.Short cannot be cast to class
java.lang.Integer (java.lang.Short and java.lang.Integer are in module
java.base of loader 'bootstrap')}}
{{ at Baz$1$1.moveNext(Unknown Source)}}
{{ at
org.apache.calcite.linq4j.Linq4j$EnumeratorIterator.(Linq4j.java:679)}}
was:
The _empid_ column is of type {_}INT{_}. When providing a _short_ value as a
placeholder, a _ClassCastException_ is thrown.
*Test case:*
{{ final String sql =}}
{{ "select \"empid\" from \"hr\".\"emps\" where \"empid\" in (?,
?)";}}{{ CalciteAssert.hr()}}
{{ .query(sql)}}
{{ .consumesPreparedStatement(p -> {}}
{{ p.setShort(1, (short) 100);}}
{{ p.setShort(2, (short) 110);}}
{{ })}}
{{ .returnsUnordered("empid=100", "empid=110");}}
*Stack trace:*
}}{}}}{{{}java.lang.ClassCastException: class java.lang.Short cannot be
cast to class java.lang.Integer (java.lang.Short and java.lang.Integer are in
module java.base of loader 'bootstrap'){}}}
{{ at Baz$1$1.moveNext(Unknown Source)}}
{{ at
org.apache.calcite.linq4j.Linq4j$EnumeratorIterator.(Linq4j.java:679)}}
> Cannot provide different numeric type as placeholder
>
>
> Key: CALCITE-6265
> URL: https://issues.apache.org/jira/browse/CALCITE-6265
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Tim Nieradzik
>Assignee: Tim Nieradzik
>Priority: Major
>
> The _empid_ column is of type {_}INT{_}. When providing a _short_ value as a
> placeholder, a _ClassCastException_ is thrown.
> *Test case:*
> {{ final String sql =}}
> {{ "select \"empid\" from \"hr\".\"emps\" where \"empid\" in (?,
> ?)";}}{{ CalciteAssert.hr()}}
> {{ .query(sql)}}
> {{ .consumesPreparedStatement(p -> {}}
> {{ p.setShort(1, (short) 100);}}
> {{ p.setShort(2, (short) 110);}}
> {{ })}}
> {{ .returnsUnordered("empid=100", "empid=110");}}
> *Stack trace:*
> {{java.lang.ClassCastException: class java.lang.Short cannot be cast to class
> java.lang.Integer (java.lang.Short and java.lang.Integer are in module
> java.base of loader 'bootstrap')}}
> {{ at Baz$1$1.moveNext(Unknown Source)}}
> {{ at
> org.apache.calcite.linq4j.Linq4j$EnumeratorIterator.(Linq4j.java:679)}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6265) Cannot provide different numeric type as placeholder
[
https://issues.apache.org/jira/browse/CALCITE-6265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Nieradzik updated CALCITE-6265:
---
Description:
The `empid` column is of type `INT`. When providing a `short` value as a
placeholder, a `ClassCastException` is thrown.
*Test case:*
{{ final String sql =}}
{{ "select \"empid\" from \"hr\".\"emps\" where \"empid\" in (?,
?)";}}{{ CalciteAssert.hr()}}
{{ .query(sql)}}
{{ .consumesPreparedStatement(p -> {}}
{{ p.setShort(1, (short) 100);}}
{{ p.setShort(2, (short) 110);}}
{{ })}}
{{ .returnsUnordered("empid=100", "empid=110");}}
*Stack trace:*
{{{}{}}}{{{}java.lang.ClassCastException: class java.lang.Short cannot be cast
to class java.lang.Integer (java.lang.Short and java.lang.Integer are in module
java.base of loader 'bootstrap'){}}}
{{ at Baz$1$1.moveNext(Unknown Source)}}
{{ at
org.apache.calcite.linq4j.Linq4j$EnumeratorIterator.(Linq4j.java:679)}}
was:
The `empid` column is of type `INT`. When providing a `short` value as a
placeholder, a `ClassCastException` is thrown.
```java
final String sql =
"select \"empid\" from \"hr\".\"emps\" where \"empid\" in (?, ?)";
CalciteAssert.hr()
.query(sql)
.consumesPreparedStatement(p -> {
p.setShort(1, (short) 100);
p.setShort(2, (short) 110);
})
.returnsUnordered("empid=100", "empid=110");
```
Stack trace:
```
java.lang.ClassCastException: class java.lang.Short cannot be cast to class
java.lang.Integer (java.lang.Short and java.lang.Integer are in module
java.base of loader 'bootstrap')
at Baz$1$1.moveNext(Unknown Source)
at
org.apache.calcite.linq4j.Linq4j$EnumeratorIterator.(Linq4j.java:679)
```
> Cannot provide different numeric type as placeholder
>
>
> Key: CALCITE-6265
> URL: https://issues.apache.org/jira/browse/CALCITE-6265
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Tim Nieradzik
>Assignee: Tim Nieradzik
>Priority: Major
>
> The `empid` column is of type `INT`. When providing a `short` value as a
> placeholder, a `ClassCastException` is thrown.
> *Test case:*
> {{ final String sql =}}
> {{ "select \"empid\" from \"hr\".\"emps\" where \"empid\" in (?,
> ?)";}}{{ CalciteAssert.hr()}}
> {{ .query(sql)}}
> {{ .consumesPreparedStatement(p -> {}}
> {{ p.setShort(1, (short) 100);}}
> {{ p.setShort(2, (short) 110);}}
> {{ })}}
> {{ .returnsUnordered("empid=100", "empid=110");}}
> *Stack trace:*
> {{{}{}}}{{{}java.lang.ClassCastException: class java.lang.Short cannot be
> cast to class java.lang.Integer (java.lang.Short and java.lang.Integer are in
> module java.base of loader 'bootstrap'){}}}
> {{ at Baz$1$1.moveNext(Unknown Source)}}
> {{ at
> org.apache.calcite.linq4j.Linq4j$EnumeratorIterator.(Linq4j.java:679)}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6265) Cannot provide different numeric type as placeholder
[
https://issues.apache.org/jira/browse/CALCITE-6265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Nieradzik updated CALCITE-6265:
---
Description:
The _empid_ column is of type {_}INT{_}. When providing a _short_ value as a
placeholder, a _ClassCastException_ is thrown.
*Test case:*
{{ final String sql =}}
{{ "select \"empid\" from \"hr\".\"emps\" where \"empid\" in (?,
?)";}}{{ CalciteAssert.hr()}}
{{ .query(sql)}}
{{ .consumesPreparedStatement(p -> {}}
{{ p.setShort(1, (short) 100);}}
{{ p.setShort(2, (short) 110);}}
{{ })}}
{{ .returnsUnordered("empid=100", "empid=110");}}
*Stack trace:*
}}{}}}{{{}java.lang.ClassCastException: class java.lang.Short cannot be
cast to class java.lang.Integer (java.lang.Short and java.lang.Integer are in
module java.base of loader 'bootstrap'){}}}
{{ at Baz$1$1.moveNext(Unknown Source)}}
{{ at
org.apache.calcite.linq4j.Linq4j$EnumeratorIterator.(Linq4j.java:679)}}
was:
The `empid` column is of type `INT`. When providing a `short` value as a
placeholder, a `ClassCastException` is thrown.
*Test case:*
{{ final String sql =}}
{{ "select \"empid\" from \"hr\".\"emps\" where \"empid\" in (?,
?)";}}{{ CalciteAssert.hr()}}
{{ .query(sql)}}
{{ .consumesPreparedStatement(p -> {}}
{{ p.setShort(1, (short) 100);}}
{{ p.setShort(2, (short) 110);}}
{{ })}}
{{ .returnsUnordered("empid=100", "empid=110");}}
*Stack trace:*
{{{}{}}}{{{}java.lang.ClassCastException: class java.lang.Short cannot be cast
to class java.lang.Integer (java.lang.Short and java.lang.Integer are in module
java.base of loader 'bootstrap'){}}}
{{ at Baz$1$1.moveNext(Unknown Source)}}
{{ at
org.apache.calcite.linq4j.Linq4j$EnumeratorIterator.(Linq4j.java:679)}}
> Cannot provide different numeric type as placeholder
>
>
> Key: CALCITE-6265
> URL: https://issues.apache.org/jira/browse/CALCITE-6265
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Tim Nieradzik
>Assignee: Tim Nieradzik
>Priority: Major
>
> The _empid_ column is of type {_}INT{_}. When providing a _short_ value as a
> placeholder, a _ClassCastException_ is thrown.
> *Test case:*
> {{ final String sql =}}
> {{ "select \"empid\" from \"hr\".\"emps\" where \"empid\" in (?,
> ?)";}}{{ CalciteAssert.hr()}}
> {{ .query(sql)}}
> {{ .consumesPreparedStatement(p -> {}}
> {{ p.setShort(1, (short) 100);}}
> {{ p.setShort(2, (short) 110);}}
> {{ })}}
> {{ .returnsUnordered("empid=100", "empid=110");}}
> *Stack trace:*
> }}{}}}{{{}java.lang.ClassCastException: class java.lang.Short cannot be
> cast to class java.lang.Integer (java.lang.Short and java.lang.Integer are in
> module java.base of loader 'bootstrap'){}}}
> {{ at Baz$1$1.moveNext(Unknown Source)}}
> {{ at
> org.apache.calcite.linq4j.Linq4j$EnumeratorIterator.(Linq4j.java:679)}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-6265) Cannot provide different numeric type as placeholder
Tim Nieradzik created CALCITE-6265:
--
Summary: Cannot provide different numeric type as placeholder
Key: CALCITE-6265
URL: https://issues.apache.org/jira/browse/CALCITE-6265
Project: Calcite
Issue Type: Bug
Components: core
Reporter: Tim Nieradzik
Assignee: Tim Nieradzik
The `empid` column is of type `INT`. When providing a `short` value as a
placeholder, a `ClassCastException` is thrown.
```java
final String sql =
"select \"empid\" from \"hr\".\"emps\" where \"empid\" in (?, ?)";
CalciteAssert.hr()
.query(sql)
.consumesPreparedStatement(p -> {
p.setShort(1, (short) 100);
p.setShort(2, (short) 110);
})
.returnsUnordered("empid=100", "empid=110");
```
Stack trace:
```
java.lang.ClassCastException: class java.lang.Short cannot be cast to class
java.lang.Integer (java.lang.Short and java.lang.Integer are in module
java.base of loader 'bootstrap')
at Baz$1$1.moveNext(Unknown Source)
at
org.apache.calcite.linq4j.Linq4j$EnumeratorIterator.(Linq4j.java:679)
```
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6261) RelBuilder.aggregate() field pruning does not use permuted field indices when used with force project and duplicate agg calls
[
https://issues.apache.org/jira/browse/CALCITE-6261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817432#comment-17817432
]
Julian Hyde commented on CALCITE-6261:
--
[~zrlpar], Thanks for taking this on. I have set fixVersion to 1.37, not to
pressure you, just to remind us (me) to follow up and review any PR you may
produce.
> RelBuilder.aggregate() field pruning does not use permuted field indices when
> used with force project and duplicate agg calls
> -
>
> Key: CALCITE-6261
> URL: https://issues.apache.org/jira/browse/CALCITE-6261
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0, 1.36.0
>Reporter: Niels Pardon
>Assignee: Niels Pardon
>Priority: Major
> Fix For: 1.37.0
>
>
> We were running into issues with RelBuilder.aggregate() when we tried to
> upgrade our code from Calcite 1.32.0 to 1.36.0 and after some debugging it
> seems this is caused by changes introduced with CALCITE-4334.
> I was able to put together this test case for RelBuilderTest reproducing the
> issue:
> {code:java}
> @Test void testAggregateForceProject() {
> final Function f1 = builder ->
> builder.scan("EMP")
> .project(
> ImmutableList.of(
> builder.field("EMPNO"),
> builder.field("ENAME"),
> builder.field("JOB"),
> builder.field("MGR"),
> builder.field("HIREDATE"),
> builder.field("SAL"),
> builder.field("COMM"),
> builder.field("DEPTNO")),
> ImmutableList.of(),
> true);
> final Function f2 = builder ->
> builder.aggregate(
> builder.groupKey(builder.field("MGR")),
> builder.avg(false, "SALARY_AVG", builder.field("SAL")),
> builder.sum(false, "SALARY_SUM", builder.field("SAL")),
> builder.avg(false, "SALARY_MEAN", builder.field("SAL")));
> final String expected = ""
> + "LogicalProject(MGR=[$0], SALARY_AVG=[$1], SALARY_SUM=[$2],
> SALARY_MEAN=[$1])\n"
> + " LogicalAggregate(group=[{0}], SALARY_AVG=[AVG($1)],
> SALARY_SUM=[SUM($1)])\n"
> + "LogicalProject(MGR=[$3], SAL=[$5])\n"
> + " LogicalTableScan(table=[[scott, EMP]])\n";
> assertThat(f2.apply(f1.apply(createBuilder())).build(), hasTree(expected));
> } {code}
> With Calcite 1.36.0 you will get an AssertionError:
> {code:java}
> java.lang.AssertionError
> at org.apache.calcite.rel.core.Aggregate.(Aggregate.java:175)
> at
> org.apache.calcite.rel.logical.LogicalAggregate.(LogicalAggregate.java:72)
> at
> org.apache.calcite.rel.logical.LogicalAggregate.create_(LogicalAggregate.java:144)
> at
> org.apache.calcite.rel.logical.LogicalAggregate.create(LogicalAggregate.java:116)
> at
> org.apache.calcite.rel.core.RelFactories$AggregateFactoryImpl.createAggregate(RelFactories.java:333)
> at org.apache.calcite.tools.RelBuilder.aggregate_(RelBuilder.java:2576)
> at org.apache.calcite.tools.RelBuilder.aggregate_(RelBuilder.java:2523)
> at org.apache.calcite.tools.RelBuilder.aggregate(RelBuilder.java:2335)
> at
> org.apache.calcite.test.RelBuilderTest.lambda$testAggregateForceProject$36(RelBuilderTest.java:1509)
> at
> org.apache.calcite.test.RelBuilderTest.testAggregateForceProject(RelBuilderTest.java:1522)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
> at
> org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
> at
> org.junit.jupiter.engine.extension.SameThreadTimeoutInvocation.proceed(SameThreadTimeoutInvocation.java:45)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86)
> at
>
[jira] [Updated] (CALCITE-6261) RelBuilder.aggregate() field pruning does not use permuted field indices when used with force project and duplicate agg calls
[
https://issues.apache.org/jira/browse/CALCITE-6261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-6261:
-
Fix Version/s: 1.37.0
> RelBuilder.aggregate() field pruning does not use permuted field indices when
> used with force project and duplicate agg calls
> -
>
> Key: CALCITE-6261
> URL: https://issues.apache.org/jira/browse/CALCITE-6261
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0, 1.36.0
>Reporter: Niels Pardon
>Assignee: Niels Pardon
>Priority: Major
> Fix For: 1.37.0
>
>
> We were running into issues with RelBuilder.aggregate() when we tried to
> upgrade our code from Calcite 1.32.0 to 1.36.0 and after some debugging it
> seems this is caused by changes introduced with CALCITE-4334.
> I was able to put together this test case for RelBuilderTest reproducing the
> issue:
> {code:java}
> @Test void testAggregateForceProject() {
> final Function f1 = builder ->
> builder.scan("EMP")
> .project(
> ImmutableList.of(
> builder.field("EMPNO"),
> builder.field("ENAME"),
> builder.field("JOB"),
> builder.field("MGR"),
> builder.field("HIREDATE"),
> builder.field("SAL"),
> builder.field("COMM"),
> builder.field("DEPTNO")),
> ImmutableList.of(),
> true);
> final Function f2 = builder ->
> builder.aggregate(
> builder.groupKey(builder.field("MGR")),
> builder.avg(false, "SALARY_AVG", builder.field("SAL")),
> builder.sum(false, "SALARY_SUM", builder.field("SAL")),
> builder.avg(false, "SALARY_MEAN", builder.field("SAL")));
> final String expected = ""
> + "LogicalProject(MGR=[$0], SALARY_AVG=[$1], SALARY_SUM=[$2],
> SALARY_MEAN=[$1])\n"
> + " LogicalAggregate(group=[{0}], SALARY_AVG=[AVG($1)],
> SALARY_SUM=[SUM($1)])\n"
> + "LogicalProject(MGR=[$3], SAL=[$5])\n"
> + " LogicalTableScan(table=[[scott, EMP]])\n";
> assertThat(f2.apply(f1.apply(createBuilder())).build(), hasTree(expected));
> } {code}
> With Calcite 1.36.0 you will get an AssertionError:
> {code:java}
> java.lang.AssertionError
> at org.apache.calcite.rel.core.Aggregate.(Aggregate.java:175)
> at
> org.apache.calcite.rel.logical.LogicalAggregate.(LogicalAggregate.java:72)
> at
> org.apache.calcite.rel.logical.LogicalAggregate.create_(LogicalAggregate.java:144)
> at
> org.apache.calcite.rel.logical.LogicalAggregate.create(LogicalAggregate.java:116)
> at
> org.apache.calcite.rel.core.RelFactories$AggregateFactoryImpl.createAggregate(RelFactories.java:333)
> at org.apache.calcite.tools.RelBuilder.aggregate_(RelBuilder.java:2576)
> at org.apache.calcite.tools.RelBuilder.aggregate_(RelBuilder.java:2523)
> at org.apache.calcite.tools.RelBuilder.aggregate(RelBuilder.java:2335)
> at
> org.apache.calcite.test.RelBuilderTest.lambda$testAggregateForceProject$36(RelBuilderTest.java:1509)
> at
> org.apache.calcite.test.RelBuilderTest.testAggregateForceProject(RelBuilderTest.java:1522)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
> at
> org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
> at
> org.junit.jupiter.engine.extension.SameThreadTimeoutInvocation.proceed(SameThreadTimeoutInvocation.java:45)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93)
> at
>
[jira] [Resolved] (CALCITE-5888) Assertion error in aggregate
[
https://issues.apache.org/jira/browse/CALCITE-5888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde resolved CALCITE-5888.
--
Fix Version/s: 1.37.0
Resolution: Duplicate
Marking resolved as a duplicate; all work can go through the other issue. I
only ask that the fix contains a test case that clearly covers the test case in
this issue.
> Assertion error in aggregate
>
>
> Key: CALCITE-5888
> URL: https://issues.apache.org/jira/browse/CALCITE-5888
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0, 1.36.0
>Reporter: Petr Masopust
>Assignee: Niels Pardon
>Priority: Major
> Fix For: 1.37.0
>
>
> We have {{relBuilder.aggregate(groupKey, aggregateCalls)}} in our code with
> values {{[AS($31, 'a_label_d_opp_stage_id_foodmart_bd4c9c91212f9f'),
> AS(CAST(FLOOR($34, FLAG(QUARTER))):TIMESTAMP(0),
> 'a_label_snapshot_timestamp_quarter_foodmart_89fe710c8628d9')]}} and
> {{[COUNT(CASE(AND(COALESCE($37, false), =($36, $13)), $15, null:NULL)),
> SUM(CASE(AND(COALESCE($37, false), =($36, $13)), $2, null:NULL)),
> MAX(CASE(AND(COALESCE($37, false), =($36, $13)), 0, null:NULL)),
> MAX(CASE(AND(COALESCE($37, false), =($36, $13)), 0, null:NULL))].}}
> It works perfectly in version 1.34.0 but in 1.35.0 we got this exception:
> {{java.lang.AssertionError}}
> {{ at org.apache.calcite.rel.core.Aggregate.(Aggregate.java:175)}}
> {{ at
> org.apache.calcite.rel.logical.LogicalAggregate.(LogicalAggregate.java:72)}}
> {{ at
> org.apache.calcite.rel.logical.LogicalAggregate.create_(LogicalAggregate.java:144)}}
> {{ at
> org.apache.calcite.rel.logical.LogicalAggregate.create(LogicalAggregate.java:116)}}
> {{ at
> org.apache.calcite.rel.core.RelFactories$AggregateFactoryImpl.createAggregate(RelFactories.java:328)}}
> {{ at
> org.apache.calcite.tools.RelBuilder.aggregate_(RelBuilder.java:2564)}}
> {{ at
> org.apache.calcite.tools.RelBuilder.aggregate_(RelBuilder.java:2511)}}
> {{ at org.apache.calcite.tools.RelBuilder.aggregate(RelBuilder.java:2348)}}
>
> I think it is either missing {{permute}} or assert should compare
> {{cardinality}} instead of {{length.}} Because it compares field index? to
> number of fields which looks like nonsense to me.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (CALCITE-6261) RelBuilder.aggregate() field pruning does not use permuted field indices when used with force project and duplicate agg calls
[
https://issues.apache.org/jira/browse/CALCITE-6261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niels Pardon reassigned CALCITE-6261:
-
Assignee: Niels Pardon
> RelBuilder.aggregate() field pruning does not use permuted field indices when
> used with force project and duplicate agg calls
> -
>
> Key: CALCITE-6261
> URL: https://issues.apache.org/jira/browse/CALCITE-6261
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0, 1.36.0
>Reporter: Niels Pardon
>Assignee: Niels Pardon
>Priority: Major
>
> We were running into issues with RelBuilder.aggregate() when we tried to
> upgrade our code from Calcite 1.32.0 to 1.36.0 and after some debugging it
> seems this is caused by changes introduced with CALCITE-4334.
> I was able to put together this test case for RelBuilderTest reproducing the
> issue:
> {code:java}
> @Test void testAggregateForceProject() {
> final Function f1 = builder ->
> builder.scan("EMP")
> .project(
> ImmutableList.of(
> builder.field("EMPNO"),
> builder.field("ENAME"),
> builder.field("JOB"),
> builder.field("MGR"),
> builder.field("HIREDATE"),
> builder.field("SAL"),
> builder.field("COMM"),
> builder.field("DEPTNO")),
> ImmutableList.of(),
> true);
> final Function f2 = builder ->
> builder.aggregate(
> builder.groupKey(builder.field("MGR")),
> builder.avg(false, "SALARY_AVG", builder.field("SAL")),
> builder.sum(false, "SALARY_SUM", builder.field("SAL")),
> builder.avg(false, "SALARY_MEAN", builder.field("SAL")));
> final String expected = ""
> + "LogicalProject(MGR=[$0], SALARY_AVG=[$1], SALARY_SUM=[$2],
> SALARY_MEAN=[$1])\n"
> + " LogicalAggregate(group=[{0}], SALARY_AVG=[AVG($1)],
> SALARY_SUM=[SUM($1)])\n"
> + "LogicalProject(MGR=[$3], SAL=[$5])\n"
> + " LogicalTableScan(table=[[scott, EMP]])\n";
> assertThat(f2.apply(f1.apply(createBuilder())).build(), hasTree(expected));
> } {code}
> With Calcite 1.36.0 you will get an AssertionError:
> {code:java}
> java.lang.AssertionError
> at org.apache.calcite.rel.core.Aggregate.(Aggregate.java:175)
> at
> org.apache.calcite.rel.logical.LogicalAggregate.(LogicalAggregate.java:72)
> at
> org.apache.calcite.rel.logical.LogicalAggregate.create_(LogicalAggregate.java:144)
> at
> org.apache.calcite.rel.logical.LogicalAggregate.create(LogicalAggregate.java:116)
> at
> org.apache.calcite.rel.core.RelFactories$AggregateFactoryImpl.createAggregate(RelFactories.java:333)
> at org.apache.calcite.tools.RelBuilder.aggregate_(RelBuilder.java:2576)
> at org.apache.calcite.tools.RelBuilder.aggregate_(RelBuilder.java:2523)
> at org.apache.calcite.tools.RelBuilder.aggregate(RelBuilder.java:2335)
> at
> org.apache.calcite.test.RelBuilderTest.lambda$testAggregateForceProject$36(RelBuilderTest.java:1509)
> at
> org.apache.calcite.test.RelBuilderTest.testAggregateForceProject(RelBuilderTest.java:1522)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
> at
> org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
> at
> org.junit.jupiter.engine.extension.SameThreadTimeoutInvocation.proceed(SameThreadTimeoutInvocation.java:45)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93)
> at
>
[jira] [Assigned] (CALCITE-5888) Assertion error in aggregate
[
https://issues.apache.org/jira/browse/CALCITE-5888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niels Pardon reassigned CALCITE-5888:
-
Assignee: Niels Pardon
> Assertion error in aggregate
>
>
> Key: CALCITE-5888
> URL: https://issues.apache.org/jira/browse/CALCITE-5888
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0, 1.36.0
>Reporter: Petr Masopust
>Assignee: Niels Pardon
>Priority: Major
>
> We have {{relBuilder.aggregate(groupKey, aggregateCalls)}} in our code with
> values {{[AS($31, 'a_label_d_opp_stage_id_foodmart_bd4c9c91212f9f'),
> AS(CAST(FLOOR($34, FLAG(QUARTER))):TIMESTAMP(0),
> 'a_label_snapshot_timestamp_quarter_foodmart_89fe710c8628d9')]}} and
> {{[COUNT(CASE(AND(COALESCE($37, false), =($36, $13)), $15, null:NULL)),
> SUM(CASE(AND(COALESCE($37, false), =($36, $13)), $2, null:NULL)),
> MAX(CASE(AND(COALESCE($37, false), =($36, $13)), 0, null:NULL)),
> MAX(CASE(AND(COALESCE($37, false), =($36, $13)), 0, null:NULL))].}}
> It works perfectly in version 1.34.0 but in 1.35.0 we got this exception:
> {{java.lang.AssertionError}}
> {{ at org.apache.calcite.rel.core.Aggregate.(Aggregate.java:175)}}
> {{ at
> org.apache.calcite.rel.logical.LogicalAggregate.(LogicalAggregate.java:72)}}
> {{ at
> org.apache.calcite.rel.logical.LogicalAggregate.create_(LogicalAggregate.java:144)}}
> {{ at
> org.apache.calcite.rel.logical.LogicalAggregate.create(LogicalAggregate.java:116)}}
> {{ at
> org.apache.calcite.rel.core.RelFactories$AggregateFactoryImpl.createAggregate(RelFactories.java:328)}}
> {{ at
> org.apache.calcite.tools.RelBuilder.aggregate_(RelBuilder.java:2564)}}
> {{ at
> org.apache.calcite.tools.RelBuilder.aggregate_(RelBuilder.java:2511)}}
> {{ at org.apache.calcite.tools.RelBuilder.aggregate(RelBuilder.java:2348)}}
>
> I think it is either missing {{permute}} or assert should compare
> {{cardinality}} instead of {{length.}} Because it compares field index? to
> number of fields which looks like nonsense to me.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6210) Cast to VARBINARY causes an assertion failure
[
https://issues.apache.org/jira/browse/CALCITE-6210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817314#comment-17817314
]
Gonzalo Ortiz commented on CALCITE-6210:
As said, I'm very new to this. But AFAIU the rewrite is done _after_ type
inference. Correct me if I'm wrong, but I though the order was:
* Parsing (transforms from String to SqlNode)
* Validation (transforms from SqlNode to Rel). Type inference is done here.
* Optimization (my transformation is done here)
The transformation I'm applying may be naive, but it is done when types
match and is preserving the types. Specifically, it is rewriting
`cast(strExpression as VARBINARY)` as `hexToBinary(strExpression)` and
`hexToBinary` is a function that takes a single argument of type String
(aka VARCHAR) and transforms it to VARBINARY. I guess I'm relaxing the
types because the same code is applied when `strExpression` is CHAR[N] and
also when casting to BINARY, but in Pinot BINARY and VARBINARY are the same
type (and the same happens with CHAR[n] and VARCHAR).
El mar, 13 feb 2024 a las 23:28, Mihai Budiu (Jira) ()
> Cast to VARBINARY causes an assertion failure
> -
>
> Key: CALCITE-6210
> URL: https://issues.apache.org/jira/browse/CALCITE-6210
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Mihai Budiu
>Priority: Minor
> Labels: pull-request-available
>
> This test in SqlOperatorTest:
> {code:java}
> SqlOperatorFixture f = fixture();
> f.checkScalar("CAST('00' AS VARBINARY)", "00", "VARBINARY NOT NULL");
> {code}
> Causes the following assertion failure:
> {code}
> java.lang.AssertionError: value 00 does not match type class
> org.apache.calcite.avatica.util.ByteString
> at
> org.apache.calcite.linq4j.tree.ConstantExpression.(ConstantExpression.java:51)
> at
> org.apache.calcite.linq4j.tree.Expressions.constant(Expressions.java:585)
> at
> org.apache.calcite.linq4j.tree.OptimizeShuttle.visit(OptimizeShuttle.java:305)
> at
> org.apache.calcite.linq4j.tree.UnaryExpression.accept(UnaryExpression.java:39)
> at
> org.apache.calcite.linq4j.tree.TernaryExpression.accept(TernaryExpression.java:47)
> at
> org.apache.calcite.linq4j.tree.DeclarationStatement.accept(DeclarationStatement.java:45)
> at
> org.apache.calcite.linq4j.tree.DeclarationStatement.accept(DeclarationStatement.java:27)
> at
> org.apache.calcite.linq4j.tree.BlockBuilder.optimize(BlockBuilder.java:426)
> at
> org.apache.calcite.linq4j.tree.BlockBuilder.toBlock(BlockBuilder.java:340)
> at
> org.apache.calcite.rex.RexExecutorImpl.compile(RexExecutorImpl.java:102)
> at
> org.apache.calcite.rex.RexExecutorImpl.compile(RexExecutorImpl.java:68)
> at
> org.apache.calcite.rex.RexExecutorImpl.reduce(RexExecutorImpl.java:133)
> at
> org.apache.calcite.rex.RexSimplify.simplifyCast(RexSimplify.java:2272)
> at org.apache.calcite.rex.RexSimplify.simplify(RexSimplify.java:292)
> at
> org.apache.calcite.rex.RexSimplify.simplifyUnknownAs(RexSimplify.java:250)
> at
> org.apache.calcite.rex.RexSimplify.simplifyPreservingType(RexSimplify.java:189)
> at
> org.apache.calcite.rex.RexSimplify.simplifyPreservingType(RexSimplify.java:184)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-6264) Implement ST functions for the TWKB format
Bertil Chapuis created CALCITE-6264: --- Summary: Implement ST functions for the TWKB format Key: CALCITE-6264 URL: https://issues.apache.org/jira/browse/CALCITE-6264 Project: Calcite Issue Type: New Feature Reporter: Bertil Chapuis TWKB is a popular format supported by postgis. Calcite does not have support for the related ST functions (ST_AsTWKB, ST_GeomFromTWKB). JTS recenlty added support for TWKB so the implementation of these functions should be rather straight forward. [https://locationtech.github.io/jts/javadoc-io/index.html] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6249) RelNode::estimatedRowCount should not be used in computeSelfCost
[
https://issues.apache.org/jira/browse/CALCITE-6249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ruben Q L updated CALCITE-6249:
---
Fix Version/s: 1.37.0
> RelNode::estimatedRowCount should not be used in computeSelfCost
>
>
> Key: CALCITE-6249
> URL: https://issues.apache.org/jira/browse/CALCITE-6249
> Project: Calcite
> Issue Type: Bug
>Reporter: Ulrich Kramer
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.37.0
>
>
> {{RelNode::estimatedRowCount}} is still used in many place inside
> {{computeSelfCost}}
> If it should be possible to implement the estimation of the row count
> completely outside Calcite, these calls should be replaced by
> {{mq.getRowCount(rel)}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-6263) Discuss the coupling of Calcite with JTS
Bertil Chapuis created CALCITE-6263: --- Summary: Discuss the coupling of Calcite with JTS Key: CALCITE-6263 URL: https://issues.apache.org/jira/browse/CALCITE-6263 Project: Calcite Issue Type: New Feature Components: jdbc-adapter Reporter: Bertil Chapuis In order to push ST functions down to Postgis in the JDBC adapter, it is necessary to register a type family for geometries in [RelDataTypeFactoryImpl.java|https://github.com/apache/calcite/pull/3668/files#diff-0fa7bd8b0354c8a4c331efa4107242e49c5d521f31adbb71388bcbc9acb7a384]. This changes increases the coupling of Calcite to a geometry library such as JTS. As this is an architectural change, a few options can be considered: # Accepting the coupling of Calcite with JTS. # Introducing an abstraction for geometry libraries in Calcite. # Using reflection to register the type family only if JTS is available in the classpath. Personally, I have a preference for options 1 and 3. Option 3, which is currently implemented in [CALCITE-6239|https://github.com/apache/calcite/pull/3668] has little impact on the current behavior. Option 2 would introduce some additional complexity. For context, here is a [link|https://github.com/apache/calcite/pull/3668#discussion_r1486925458] to the original discussion. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (CALCITE-6157) SqlValidatorImpl breaks join condition when inlining table alias
[
https://issues.apache.org/jira/browse/CALCITE-6157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817245#comment-17817245
]
Corvin Kuebler edited comment on CALCITE-6157 at 2/14/24 8:26 AM:
--
We recently ran into the same issue again (other context but similar query).
Since we are still unsure of the exact conditions of this happening and the
error messages we get are quite missleading I'll go ahead and add an
RTException that atleast hints at the root cause of the isue.
was (Author: JIRAUSER299611):
We recently ran into the same issue again (other context but similar query).
I'll open a PR that throws an exception if the unusual behaviour is detected
> SqlValidatorImpl breaks join condition when inlining table alias
>
>
> Key: CALCITE-6157
> URL: https://issues.apache.org/jira/browse/CALCITE-6157
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Ulrich Kramer
>Priority: Major
> Labels: pull-request-available
>
> When switching from 1.35.0 to 1.36.0, {{SqlValidatorImpl}} breaks the join
> condition on the following statement
> {code:SQL}
> WITH `it1` AS (
> SELECT
> `company`,
> `area`,
> `revenue`,
> `regionId`
> FROM
> `12345678-1234-1234-1234-00010001`.`revenues`
> )
> SELECT
> *
> FROM
> (
> SELECT
> `T1`.`company` AS `company`,
> MAX(`T1`.`revenue`) AS `revenue`
> FROM
> `it1` AS `T1`
> GROUP BY
> `company`
> ) AS `T`
> LEFT JOIN `it1` AS `T2` ON `T`.`company` = `T2`.`company`
> AND `T`.`revenue` = `T2`.`revenue`
> {code}
> It modifies the join condition [at this
> location|https://github.com/apache/calcite/blob/d3ab0bc8e4d4c9ebc0fc4e33ce478d276f5d11e4/core/src/main/java/org/apache/calcite/sql/validate/SqlValidatorImpl.java#L3603-L3604]
> to
> {code:SQL}
> `T`.`company` = `T1`.`company`
> AND `T`.`revenue` = `T1`.`revenue`
> {code}
> which causes a "{{Table `T1`not found}}" exception.
> I already tried to reproduce the problem by adding the following test to
> {{SqlValidatorTest}}, but everything worked fine
> {code:java}
> @Test void testWith2() {
> sql("with it1 as (select empno, sal, deptno from emp)\n"
> + "select * from ( select t1.empno as empno, max(t1.deptno) as deptno
> from it1 as t1 group by empno) as t\n"
> + "left outer join it1 as t2 on t.empno = t2.empno and t.deptno =
> t2.deptno")
> .ok();
> }
> {code}
> During debugging, I recognized that the {{DelegatingScope}} does something
> different in our case [at this
> location|https://github.com/apache/calcite/blob/d3ab0bc8e4d4c9ebc0fc4e33ce478d276f5d11e4/core/src/main/java/org/apache/calcite/sql/validate/DelegatingScope.java#L333-L337].
> In our case the {{fromNs}} resolved to {{`it1` AS `T1`}}, which is wrong.
> But I was not able to find the root cause yet.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6157) SqlValidatorImpl breaks join condition when inlining table alias
[
https://issues.apache.org/jira/browse/CALCITE-6157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6157:
Labels: pull-request-available (was: )
> SqlValidatorImpl breaks join condition when inlining table alias
>
>
> Key: CALCITE-6157
> URL: https://issues.apache.org/jira/browse/CALCITE-6157
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Ulrich Kramer
>Priority: Major
> Labels: pull-request-available
>
> When switching from 1.35.0 to 1.36.0, {{SqlValidatorImpl}} breaks the join
> condition on the following statement
> {code:SQL}
> WITH `it1` AS (
> SELECT
> `company`,
> `area`,
> `revenue`,
> `regionId`
> FROM
> `12345678-1234-1234-1234-00010001`.`revenues`
> )
> SELECT
> *
> FROM
> (
> SELECT
> `T1`.`company` AS `company`,
> MAX(`T1`.`revenue`) AS `revenue`
> FROM
> `it1` AS `T1`
> GROUP BY
> `company`
> ) AS `T`
> LEFT JOIN `it1` AS `T2` ON `T`.`company` = `T2`.`company`
> AND `T`.`revenue` = `T2`.`revenue`
> {code}
> It modifies the join condition [at this
> location|https://github.com/apache/calcite/blob/d3ab0bc8e4d4c9ebc0fc4e33ce478d276f5d11e4/core/src/main/java/org/apache/calcite/sql/validate/SqlValidatorImpl.java#L3603-L3604]
> to
> {code:SQL}
> `T`.`company` = `T1`.`company`
> AND `T`.`revenue` = `T1`.`revenue`
> {code}
> which causes a "{{Table `T1`not found}}" exception.
> I already tried to reproduce the problem by adding the following test to
> {{SqlValidatorTest}}, but everything worked fine
> {code:java}
> @Test void testWith2() {
> sql("with it1 as (select empno, sal, deptno from emp)\n"
> + "select * from ( select t1.empno as empno, max(t1.deptno) as deptno
> from it1 as t1 group by empno) as t\n"
> + "left outer join it1 as t2 on t.empno = t2.empno and t.deptno =
> t2.deptno")
> .ok();
> }
> {code}
> During debugging, I recognized that the {{DelegatingScope}} does something
> different in our case [at this
> location|https://github.com/apache/calcite/blob/d3ab0bc8e4d4c9ebc0fc4e33ce478d276f5d11e4/core/src/main/java/org/apache/calcite/sql/validate/DelegatingScope.java#L333-L337].
> In our case the {{fromNs}} resolved to {{`it1` AS `T1`}}, which is wrong.
> But I was not able to find the root cause yet.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6157) SqlValidatorImpl breaks join condition when inlining table alias
[
https://issues.apache.org/jira/browse/CALCITE-6157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817245#comment-17817245
]
Corvin Kuebler commented on CALCITE-6157:
-
We recently ran into the same issue again (other context but similar query).
I'll open a PR that throws an exception if the unusual behaviour is detected
> SqlValidatorImpl breaks join condition when inlining table alias
>
>
> Key: CALCITE-6157
> URL: https://issues.apache.org/jira/browse/CALCITE-6157
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Ulrich Kramer
>Priority: Major
>
> When switching from 1.35.0 to 1.36.0, {{SqlValidatorImpl}} breaks the join
> condition on the following statement
> {code:SQL}
> WITH `it1` AS (
> SELECT
> `company`,
> `area`,
> `revenue`,
> `regionId`
> FROM
> `12345678-1234-1234-1234-00010001`.`revenues`
> )
> SELECT
> *
> FROM
> (
> SELECT
> `T1`.`company` AS `company`,
> MAX(`T1`.`revenue`) AS `revenue`
> FROM
> `it1` AS `T1`
> GROUP BY
> `company`
> ) AS `T`
> LEFT JOIN `it1` AS `T2` ON `T`.`company` = `T2`.`company`
> AND `T`.`revenue` = `T2`.`revenue`
> {code}
> It modifies the join condition [at this
> location|https://github.com/apache/calcite/blob/d3ab0bc8e4d4c9ebc0fc4e33ce478d276f5d11e4/core/src/main/java/org/apache/calcite/sql/validate/SqlValidatorImpl.java#L3603-L3604]
> to
> {code:SQL}
> `T`.`company` = `T1`.`company`
> AND `T`.`revenue` = `T1`.`revenue`
> {code}
> which causes a "{{Table `T1`not found}}" exception.
> I already tried to reproduce the problem by adding the following test to
> {{SqlValidatorTest}}, but everything worked fine
> {code:java}
> @Test void testWith2() {
> sql("with it1 as (select empno, sal, deptno from emp)\n"
> + "select * from ( select t1.empno as empno, max(t1.deptno) as deptno
> from it1 as t1 group by empno) as t\n"
> + "left outer join it1 as t2 on t.empno = t2.empno and t.deptno =
> t2.deptno")
> .ok();
> }
> {code}
> During debugging, I recognized that the {{DelegatingScope}} does something
> different in our case [at this
> location|https://github.com/apache/calcite/blob/d3ab0bc8e4d4c9ebc0fc4e33ce478d276f5d11e4/core/src/main/java/org/apache/calcite/sql/validate/DelegatingScope.java#L333-L337].
> In our case the {{fromNs}} resolved to {{`it1` AS `T1`}}, which is wrong.
> But I was not able to find the root cause yet.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
