[jira] [Commented] (CALCITE-3568) BigQuery, Hive, Spark SQL dialect doesn't support nested aggregates
[ https://issues.apache.org/jira/browse/CALCITE-3568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16988563#comment-16988563 ] Rui Wang commented on CALCITE-3568: --- You will need to ask in dev@ to add you to JIRA list/group. But it's ok. You can link your PR to this JIRA, that will also be good enough. > BigQuery, Hive, Spark SQL dialect doesn't support nested aggregates > --- > > Key: CALCITE-3568 > URL: https://issues.apache.org/jira/browse/CALCITE-3568 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Divyanshu Srivastava >Priority: Major > > The BigQuerySqlDialect, HiveSqlDialect, SparkSqlDialect do not support nested > aggregates, hence overriding the supportsNestedAggregations() method in them. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3568) BigQuery SQL dialect doesn't support nested aggregates
[ https://issues.apache.org/jira/browse/CALCITE-3568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16988558#comment-16988558 ] Divyanshu Srivastava commented on CALCITE-3568: --- [~amaliujia] I have already done the code, raising a merge request. > BigQuery SQL dialect doesn't support nested aggregates > -- > > Key: CALCITE-3568 > URL: https://issues.apache.org/jira/browse/CALCITE-3568 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Divyanshu Srivastava >Priority: Major > > The BigQuerySqlDialect does not support nested aggregates, hence overriding > the supportsNestedAggregations() method in it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-3568) BigQuery, Hive, Spark SQL dialect doesn't support nested aggregates
[ https://issues.apache.org/jira/browse/CALCITE-3568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16988558#comment-16988558 ] Divyanshu Srivastava edited comment on CALCITE-3568 at 12/5/19 7:47 AM: [~amaliujia] I am unable to assign it to myself, but I have already done the code and raising a merge request. was (Author: divyanshu.s95): [~amaliujia] I have already done the code, raising a merge request. > BigQuery, Hive, Spark SQL dialect doesn't support nested aggregates > --- > > Key: CALCITE-3568 > URL: https://issues.apache.org/jira/browse/CALCITE-3568 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Divyanshu Srivastava >Priority: Major > > The BigQuerySqlDialect, HiveSqlDialect, SparkSqlDialect do not support nested > aggregates, hence overriding the supportsNestedAggregations() method in them. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-3568) BigQuery, Hive, Spark SQL dialect doesn't support nested aggregates
[ https://issues.apache.org/jira/browse/CALCITE-3568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Divyanshu Srivastava updated CALCITE-3568: -- Description: The BigQuerySqlDialect, HiveSqlDialect, SparkSqlDialect do not support nested aggregates, hence overriding the supportsNestedAggregations() method in them. (was: The BigQuerySqlDialect does not support nested aggregates, hence overriding the supportsNestedAggregations() method in it.) Summary: BigQuery, Hive, Spark SQL dialect doesn't support nested aggregates (was: BigQuery SQL dialect doesn't support nested aggregates) > BigQuery, Hive, Spark SQL dialect doesn't support nested aggregates > --- > > Key: CALCITE-3568 > URL: https://issues.apache.org/jira/browse/CALCITE-3568 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Divyanshu Srivastava >Priority: Major > > The BigQuerySqlDialect, HiveSqlDialect, SparkSqlDialect do not support nested > aggregates, hence overriding the supportsNestedAggregations() method in them. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (CALCITE-3281) Support mixed Primitive types for BinaryExpression evaluate method.
[
https://issues.apache.org/jira/browse/CALCITE-3281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Sereda reassigned CALCITE-3281:
--
Assignee: Wang Yanlin
> Support mixed Primitive types for BinaryExpression evaluate method.
>
>
> Key: CALCITE-3281
> URL: https://issues.apache.org/jira/browse/CALCITE-3281
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.21.0
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Major
> Labels: pull-request-available
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Currently, the value of [expression0 and expression1
> |https://github.com/apache/calcite/blob/master/linq4j/src/main/java/org/apache/calcite/linq4j/tree/BinaryExpression.java#L26]
> must be the same type.
> Otherwise, when evaluate, we will get a ClassCastException, something like
> this
> {code:java}
> java.lang.ClassCastException: java.lang.Integer cannot be cast to
> java.lang.Long
> at
> org.apache.calcite.linq4j.tree.BinaryExpression.evaluate(BinaryExpression.java:75)
> at
> org.apache.calcite.linq4j.tree.GotoStatement.evaluate(GotoStatement.java:97)
> at
> org.apache.calcite.linq4j.tree.BlockStatement.evaluate(BlockStatement.java:83)
> at org.apache.calcite.linq4j.tree.Evaluator.evaluate(Evaluator.java:55)
> at
> org.apache.calcite.linq4j.tree.FunctionExpression.lambda$compile$0(FunctionExpression.java:87)
> at
> org.apache.calcite.linq4j.test.ExpressionTest.testLambdaCallsBinaryOpMixType(ExpressionTest.java:349)
> 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
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> {code}
> Actually, we can do something to support mixed primitive types in
> BinaryExpression.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CALCITE-3281) Support mixed Primitive types for BinaryExpression evaluate method.
[
https://issues.apache.org/jira/browse/CALCITE-3281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Sereda resolved CALCITE-3281.
Resolution: Fixed
Fixed in
[67ed3223|https://github.com/apache/calcite/commit/67ed322370472dc4403eed485d0b61fe5a40f84f]
> Support mixed Primitive types for BinaryExpression evaluate method.
>
>
> Key: CALCITE-3281
> URL: https://issues.apache.org/jira/browse/CALCITE-3281
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.21.0
>Reporter: Wang Yanlin
>Priority: Major
> Labels: pull-request-available
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Currently, the value of [expression0 and expression1
> |https://github.com/apache/calcite/blob/master/linq4j/src/main/java/org/apache/calcite/linq4j/tree/BinaryExpression.java#L26]
> must be the same type.
> Otherwise, when evaluate, we will get a ClassCastException, something like
> this
> {code:java}
> java.lang.ClassCastException: java.lang.Integer cannot be cast to
> java.lang.Long
> at
> org.apache.calcite.linq4j.tree.BinaryExpression.evaluate(BinaryExpression.java:75)
> at
> org.apache.calcite.linq4j.tree.GotoStatement.evaluate(GotoStatement.java:97)
> at
> org.apache.calcite.linq4j.tree.BlockStatement.evaluate(BlockStatement.java:83)
> at org.apache.calcite.linq4j.tree.Evaluator.evaluate(Evaluator.java:55)
> at
> org.apache.calcite.linq4j.tree.FunctionExpression.lambda$compile$0(FunctionExpression.java:87)
> at
> org.apache.calcite.linq4j.test.ExpressionTest.testLambdaCallsBinaryOpMixType(ExpressionTest.java:349)
> 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
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> {code}
> Actually, we can do something to support mixed primitive types in
> BinaryExpression.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3281) Support mixed Primitive types for BinaryExpression evaluate method.
[
https://issues.apache.org/jira/browse/CALCITE-3281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Sereda updated CALCITE-3281:
---
Affects Version/s: 1.21.0
> Support mixed Primitive types for BinaryExpression evaluate method.
>
>
> Key: CALCITE-3281
> URL: https://issues.apache.org/jira/browse/CALCITE-3281
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.21.0
>Reporter: Wang Yanlin
>Priority: Major
> Labels: pull-request-available
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Currently, the value of [expression0 and expression1
> |https://github.com/apache/calcite/blob/master/linq4j/src/main/java/org/apache/calcite/linq4j/tree/BinaryExpression.java#L26]
> must be the same type.
> Otherwise, when evaluate, we will get a ClassCastException, something like
> this
> {code:java}
> java.lang.ClassCastException: java.lang.Integer cannot be cast to
> java.lang.Long
> at
> org.apache.calcite.linq4j.tree.BinaryExpression.evaluate(BinaryExpression.java:75)
> at
> org.apache.calcite.linq4j.tree.GotoStatement.evaluate(GotoStatement.java:97)
> at
> org.apache.calcite.linq4j.tree.BlockStatement.evaluate(BlockStatement.java:83)
> at org.apache.calcite.linq4j.tree.Evaluator.evaluate(Evaluator.java:55)
> at
> org.apache.calcite.linq4j.tree.FunctionExpression.lambda$compile$0(FunctionExpression.java:87)
> at
> org.apache.calcite.linq4j.test.ExpressionTest.testLambdaCallsBinaryOpMixType(ExpressionTest.java:349)
> 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
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> {code}
> Actually, we can do something to support mixed primitive types in
> BinaryExpression.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3281) Support mixed Primitive types for BinaryExpression evaluate method.
[
https://issues.apache.org/jira/browse/CALCITE-3281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Sereda updated CALCITE-3281:
---
Component/s: core
> Support mixed Primitive types for BinaryExpression evaluate method.
>
>
> Key: CALCITE-3281
> URL: https://issues.apache.org/jira/browse/CALCITE-3281
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.21.0
>Reporter: Wang Yanlin
>Priority: Major
> Labels: pull-request-available
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Currently, the value of [expression0 and expression1
> |https://github.com/apache/calcite/blob/master/linq4j/src/main/java/org/apache/calcite/linq4j/tree/BinaryExpression.java#L26]
> must be the same type.
> Otherwise, when evaluate, we will get a ClassCastException, something like
> this
> {code:java}
> java.lang.ClassCastException: java.lang.Integer cannot be cast to
> java.lang.Long
> at
> org.apache.calcite.linq4j.tree.BinaryExpression.evaluate(BinaryExpression.java:75)
> at
> org.apache.calcite.linq4j.tree.GotoStatement.evaluate(GotoStatement.java:97)
> at
> org.apache.calcite.linq4j.tree.BlockStatement.evaluate(BlockStatement.java:83)
> at org.apache.calcite.linq4j.tree.Evaluator.evaluate(Evaluator.java:55)
> at
> org.apache.calcite.linq4j.tree.FunctionExpression.lambda$compile$0(FunctionExpression.java:87)
> at
> org.apache.calcite.linq4j.test.ExpressionTest.testLambdaCallsBinaryOpMixType(ExpressionTest.java:349)
> 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
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> {code}
> Actually, we can do something to support mixed primitive types in
> BinaryExpression.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (CALCITE-3557) ClassCastException for using nested multiset or array inside multiset
[
https://issues.apache.org/jira/browse/CALCITE-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin reassigned CALCITE-3557:
Assignee: (was: Wang Yanlin)
> ClassCastException for using nested multiset or array inside multiset
> -
>
> Key: CALCITE-3557
> URL: https://issues.apache.org/jira/browse/CALCITE-3557
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Priority: Major
>
> {code:java}
> // JdbcTest
> @Test public void testNestedMultiset() {
> CalciteAssert.that()
> .query("select multiset[ARRAY[1, 2], ARRAY[3, 4]]")
> .returns("EXPR$0=[[1, 2], [3, 4]]\n");
> CalciteAssert.that()
> .query("select multiset[multiset[1, 2], multiset[3, 4]]")
> .returns("EXPR$0=[[1, 2], [3, 4]]\n");
> }
> {code}
> Got
> {code:java}
> java.lang.ClassCastException: [Ljava.lang.Object; cannot be cast to
> java.lang.Integer
> at
> org.apache.calcite.avatica.util.AbstractCursor$IntAccessor.getInt(AbstractCursor.java:541)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.convertValue(AbstractCursor.java:1318)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getObject(AbstractCursor.java:1299)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getArray(AbstractCursor.java:1352)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.convertValue(AbstractCursor.java:1326)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getObject(AbstractCursor.java:1299)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getArray(AbstractCursor.java:1352)
> at org.apache.calcite.avatica.AvaticaSite.get(AvaticaSite.java:305)
> at
> org.apache.calcite.avatica.AvaticaResultSet.getObject(AvaticaResultSet.java:393)
> at
> org.apache.calcite.test.CalciteAssert$ResultSetFormatter.rowToString(CalciteAssert.java:1978)
> at
> org.apache.calcite.test.CalciteAssert$ResultSetFormatter.resultSet(CalciteAssert.java:1966)
> at
> org.apache.calcite.test.CalciteAssert.lambda$checkResult$2(CalciteAssert.java:303)
> at
> org.apache.calcite.test.CalciteAssert.assertQuery(CalciteAssert.java:544)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.lambda$returns$1(CalciteAssert.java:1514)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.withConnection(CalciteAssert.java:1446)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1512)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1495)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1458)
> at
> org.apache.calcite.test.JdbcTest.testNestedMultiset(JdbcTest.java:2057)
> 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.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:33)
> at
> com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:230)
> at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:58)
> Suppressed: org.apache.calcite.util.TestUtil$ExtraInformation: With
>
[jira] [Commented] (CALCITE-3558) Columns reordering doesn't work in SplunkPushDownRule
[ https://issues.apache.org/jira/browse/CALCITE-3558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16988500#comment-16988500 ] Shawn Chen commented on CALCITE-3558: - I will update this issue later. > Columns reordering doesn't work in SplunkPushDownRule > - > > Key: CALCITE-3558 > URL: https://issues.apache.org/jira/browse/CALCITE-3558 > Project: Calcite > Issue Type: Bug > Components: splunk >Affects Versions: 1.21.0 > Environment: Splunk 7.3+ >Reporter: Shawn Chen >Assignee: Shawn Chen >Priority: Major > Labels: pull-request-available > Fix For: next > > Original Estimate: 6h > Time Spent: 6h > Remaining Estimate: 0h > > The indexing variable i doesn't increase per loop between line 233 to 246 in > SplunkPushDownRule.java. > This bug causes column reordering nonfunctional. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3570) Support MutableSnapshot in MutableRel
[ https://issues.apache.org/jira/browse/CALCITE-3570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16988480#comment-16988480 ] Jin Xing commented on CALCITE-3570: --- Can you explain in what scenario MutableSnapshot is needed ? Since it's not supported in SubstitutionVisitor at this moment. > Support MutableSnapshot in MutableRel > - > > Key: CALCITE-3570 > URL: https://issues.apache.org/jira/browse/CALCITE-3570 > Project: Calcite > Issue Type: Wish >Reporter: xzh_dz >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > Support MutableSnapshot in MutableRel.This PR implements mutual conversion > between mutablesnapshot and logicalsnapshot. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3549) Lex config for view expanding is not supported
[
https://issues.apache.org/jira/browse/CALCITE-3549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16988477#comment-16988477
]
Jin Xing commented on CALCITE-3549:
---
IIUC we should separate the lex when define a view and use a view, i.e. the lex
of a view is determined and saved into schema when created. If a connection
have different lex convention when use the view, we should use the the lex
convention from schema, rather than the lex of the connection to expand the
view.
> Lex config for view expanding is not supported
> --
>
> Key: CALCITE-3549
> URL: https://issues.apache.org/jira/browse/CALCITE-3549
> Project: Calcite
> Issue Type: Improvement
>Reporter: Jin Xing
>Priority: Major
> Labels: pull-request-available
> Time Spent: 50m
> Remaining Estimate: 0h
>
> UT as below:
> {code:java}
> // JdbcTest.java
> @Test public void testDEV() {
> modelWithView("select * from EMPLOYEES where deptno = 10", null)
> .with(Lex.JAVA)
> .query("select * from adhoc.V order by name desc")
> .returns("");
> }
> {code}
> Failed with
> {code:java}
> org.apache.calcite.sql.validate.SqlValidatorException: Column 'DEPTNO' not
> found in any table; did you mean 'deptno'?
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CALCITE-3561) Implement Uncollect relational operator in Interpreter (for SQL queries that use UNNEST)
[
https://issues.apache.org/jira/browse/CALCITE-3561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Sereda resolved CALCITE-3561.
Resolution: Fixed
Fixed in
[f1e51e6c|https://github.com/apache/calcite/commit/f1e51e6c310b68d399b360ff374ffc6d46fefdba]
> Implement Uncollect relational operator in Interpreter (for SQL queries that
> use UNNEST)
>
>
> Key: CALCITE-3561
> URL: https://issues.apache.org/jira/browse/CALCITE-3561
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.21.0
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Major
> Labels: pull-request-available
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Using unnest in Interpreter will cause exception,
> {code:java}
> // InterpreterTest
> @Test public void testInterpretUnnest() throws Exception {
> final String sql = "select * from unnest(multiset[1, 2])";
> sql(sql).returnsRows("[1]", "[2]");
> }
> {code}
> got
> {code:java}
> java.lang.AssertionError: interpreter: no implementation for class
> org.apache.calcite.rel.core.Uncollect
> at
> org.apache.calcite.interpreter.Interpreter$CompilerImpl.visit(Interpreter.java:463)
> at
> org.apache.calcite.interpreter.Nodes$CoreCompiler.visit(Nodes.java:44)
> at org.apache.calcite.rel.SingleRel.childrenAccept(SingleRel.java:72)
> at
> org.apache.calcite.interpreter.Interpreter$CompilerImpl.visit(Interpreter.java:450)
> at
> org.apache.calcite.interpreter.Nodes$CoreCompiler.visit(Nodes.java:44)
> at
> org.apache.calcite.interpreter.Interpreter$CompilerImpl.visitRoot(Interpreter.java:408)
> at
> org.apache.calcite.interpreter.Interpreter.(Interpreter.java:89)
> at
> org.apache.calcite.test.InterpreterTest$Sql.returnsRows(InterpreterTest.java:121)
> at
> org.apache.calcite.test.InterpreterTest$Sql.returnsRows(InterpreterTest.java:105)
> at
> org.apache.calcite.test.InterpreterTest.testInterpretUnnest(InterpreterTest.java:446)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> {code}
> Add support to use unnest in Interpreter.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3561) Implement Uncollect relational operator in Interpreter (for SQL queries that use UNNEST)
[
https://issues.apache.org/jira/browse/CALCITE-3561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Sereda updated CALCITE-3561:
---
Component/s: core
> Implement Uncollect relational operator in Interpreter (for SQL queries that
> use UNNEST)
>
>
> Key: CALCITE-3561
> URL: https://issues.apache.org/jira/browse/CALCITE-3561
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.21.0
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Major
> Labels: pull-request-available
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Using unnest in Interpreter will cause exception,
> {code:java}
> // InterpreterTest
> @Test public void testInterpretUnnest() throws Exception {
> final String sql = "select * from unnest(multiset[1, 2])";
> sql(sql).returnsRows("[1]", "[2]");
> }
> {code}
> got
> {code:java}
> java.lang.AssertionError: interpreter: no implementation for class
> org.apache.calcite.rel.core.Uncollect
> at
> org.apache.calcite.interpreter.Interpreter$CompilerImpl.visit(Interpreter.java:463)
> at
> org.apache.calcite.interpreter.Nodes$CoreCompiler.visit(Nodes.java:44)
> at org.apache.calcite.rel.SingleRel.childrenAccept(SingleRel.java:72)
> at
> org.apache.calcite.interpreter.Interpreter$CompilerImpl.visit(Interpreter.java:450)
> at
> org.apache.calcite.interpreter.Nodes$CoreCompiler.visit(Nodes.java:44)
> at
> org.apache.calcite.interpreter.Interpreter$CompilerImpl.visitRoot(Interpreter.java:408)
> at
> org.apache.calcite.interpreter.Interpreter.(Interpreter.java:89)
> at
> org.apache.calcite.test.InterpreterTest$Sql.returnsRows(InterpreterTest.java:121)
> at
> org.apache.calcite.test.InterpreterTest$Sql.returnsRows(InterpreterTest.java:105)
> at
> org.apache.calcite.test.InterpreterTest.testInterpretUnnest(InterpreterTest.java:446)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> {code}
> Add support to use unnest in Interpreter.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3561) Implement Uncollect relational operator in Interpreter (for SQL queries that use UNNEST)
[
https://issues.apache.org/jira/browse/CALCITE-3561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Sereda updated CALCITE-3561:
---
Affects Version/s: 1.21.0
> Implement Uncollect relational operator in Interpreter (for SQL queries that
> use UNNEST)
>
>
> Key: CALCITE-3561
> URL: https://issues.apache.org/jira/browse/CALCITE-3561
> Project: Calcite
> Issue Type: Improvement
>Affects Versions: 1.21.0
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Major
> Labels: pull-request-available
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Using unnest in Interpreter will cause exception,
> {code:java}
> // InterpreterTest
> @Test public void testInterpretUnnest() throws Exception {
> final String sql = "select * from unnest(multiset[1, 2])";
> sql(sql).returnsRows("[1]", "[2]");
> }
> {code}
> got
> {code:java}
> java.lang.AssertionError: interpreter: no implementation for class
> org.apache.calcite.rel.core.Uncollect
> at
> org.apache.calcite.interpreter.Interpreter$CompilerImpl.visit(Interpreter.java:463)
> at
> org.apache.calcite.interpreter.Nodes$CoreCompiler.visit(Nodes.java:44)
> at org.apache.calcite.rel.SingleRel.childrenAccept(SingleRel.java:72)
> at
> org.apache.calcite.interpreter.Interpreter$CompilerImpl.visit(Interpreter.java:450)
> at
> org.apache.calcite.interpreter.Nodes$CoreCompiler.visit(Nodes.java:44)
> at
> org.apache.calcite.interpreter.Interpreter$CompilerImpl.visitRoot(Interpreter.java:408)
> at
> org.apache.calcite.interpreter.Interpreter.(Interpreter.java:89)
> at
> org.apache.calcite.test.InterpreterTest$Sql.returnsRows(InterpreterTest.java:121)
> at
> org.apache.calcite.test.InterpreterTest$Sql.returnsRows(InterpreterTest.java:105)
> at
> org.apache.calcite.test.InterpreterTest.testInterpretUnnest(InterpreterTest.java:446)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> {code}
> Add support to use unnest in Interpreter.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3570) Support MutableSnapshot in MutableRel
[ https://issues.apache.org/jira/browse/CALCITE-3570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-3570: Labels: pull-request-available (was: ) > Support MutableSnapshot in MutableRel > - > > Key: CALCITE-3570 > URL: https://issues.apache.org/jira/browse/CALCITE-3570 > Project: Calcite > Issue Type: Wish >Reporter: xzh_dz >Priority: Major > Labels: pull-request-available > > Support MutableSnapshot in MutableRel.This PR implements mutual conversion > between mutablesnapshot and logicalsnapshot. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-3570) Support MutableSnapshot in MutableRel
xzh_dz created CALCITE-3570: --- Summary: Support MutableSnapshot in MutableRel Key: CALCITE-3570 URL: https://issues.apache.org/jira/browse/CALCITE-3570 Project: Calcite Issue Type: Wish Reporter: xzh_dz Support MutableSnapshot in MutableRel.This PR implements mutual conversion between mutablesnapshot and logicalsnapshot. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3563) Convert function operand type to match implementation if necessary in runtime
[
https://issues.apache.org/jira/browse/CALCITE-3563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16988423#comment-16988423
]
Feng Zhu commented on CALCITE-3563:
---
Hi [~julianhyde], it is just an illustrative example.
We can also figure out some other cases like:
{code:java}
@Test public void test0() {
final String sql = "SELECT round(1.5, cast(1 as bigint))";
CalciteAssert.that()
.query(sql)
.returns("EXPR$0=1.5\n");
}
{code}
Exception:
{code:java}
java.lang.RuntimeException: while resolving method 'sround[class
java.math.BigDecimal, long]' in class class
org.apache.calcite.runtime.SqlFunctions
{code}
Since it is the argurments types are illegal, shall we make strict check in
validation phase before entring into runtime?
> Convert function operand type to match implementation if necessary in runtime
> -
>
> Key: CALCITE-3563
> URL: https://issues.apache.org/jira/browse/CALCITE-3563
> Project: Calcite
> Issue Type: Sub-task
> Components: core
>Reporter: Feng Zhu
>Assignee: Feng Zhu
>Priority: Major
>
> Sub-task targets on following issue.
>
> (1)Validation phase allows a wide range of operand types, but the runtime
> implementation does not cover all cases.
> For example, _*SqlFunction(MOD)*_ adopts
> _*OperandTypes.EXACT_NUMERIC_EXACT_NUMERIC*_.
> {code:java}
> @Test public void test0() {
> final String sql = "SELECT mod(12.5, cast(1 as bigint))";
> CalciteAssert.that()
> .query(sql)
> .returns("EXPR$0=0.5\n");
> }{code}
> We will get:
> {code:java}
> java.lang.RuntimeException: while resolving method 'mod[class
> java.math.BigDecimal, long]' in class class
> org.apache.calcite.runtime.SqlFunctions
> at org.apache.calcite.linq4j.tree.Types.lookupMethod(Types.java:323)
> at org.apache.calcite.linq4j.tree.Expressions.call(Expressions.java:445)
> at
> org.apache.calcite.adapter.enumerable.RexImpTable$MethodNameImplementor.implement(RexImpTable.java:2253)
> at
> org.apache.calcite.adapter.enumerable.RexImpTable.implementCall(RexImpTable.java:1195){code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3478) Restructure tests for materialized views
[ https://issues.apache.org/jira/browse/CALCITE-3478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jin Xing updated CALCITE-3478: -- Summary: Restructure tests for materialized views (was: Reconstructure of materialized view tests.) > Restructure tests for materialized views > > > Key: CALCITE-3478 > URL: https://issues.apache.org/jira/browse/CALCITE-3478 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jin Xing >Assignee: Jin Xing >Priority: Major > Labels: pull-request-available > Time Spent: 1h 20m > Remaining Estimate: 0h > > h2. *Motivation* > Currently there are two strategies for materialized view matching: > *strategy-1*. Substitution based (SubstitutionVisitor.java) [1] > *strategy-2*. Plan structural information based > (AbstractMaterializedViewRule.java) [2] > The two strategies are controlled by a single connection config of > "materializationsEnabled". Calcite will apply strategy-1 firstly and then > strategy-2. > The two strategies are tested in a single integration test called > MaterializationTest.java, > As a result we cannot run tests separately for a single strategy, which > leads to: > # When some new matching patterns are supported by strategy-1, we might need > to update the old result plan, which was previously matched and generated by > stragegy-2, e.g. [3], and corresponding testing pattern for stragegy-2 will > be lost. > # Some test failures are even hidden, e.g. > MaterializationTest#testJoinMaterialization2 should but failed to be > supported by stragegy-2. However strategy-1 lets the test passed. > # Hard to test internals for SubstutionVisitor.java, e.g. [4] has to > struggle and create a unit test > Of course we can add more system config or connection config just for testing > and circle around some of the dilemmas I mentioned above. But it will make > the code messy. Materialized view matching strategies are so important and > worth a through unit test and to be kept clean. > Additionally, this JIRA targets to clean the code of > MaterializationTest.java. As more and more fixes get applied, this Java file > tends to be messy: > # Helping methods and testing methods are mixed without good order. > # Lots of methods called checkMaterialize. We need to sort it out if there's > need to add more params, e.g. [5] > # Some tests are not concise enough, e.g. testJoinMaterialization9 > h2. *Approach* > 1. Create unit test MaterializedViewSubstitutionVisitorTest to test strategy-1 > 2. Create unit test MaterializedViewRelOptRulesTest to test strategy-2 > 3. Move tests from MaterializationTest to unit tests correspondingly, and > keep MaterializationTest for integration tests. > > [1] > [https://calcite.apache.org/docs/materialized_views.html#substitution-via-rules-transformation] > [2] > [https://calcite.apache.org/docs/materialized_views.html#rewriting-using-plan-structural-information] > [3] > [https://github.com/apache/calcite/pull/1451/files#diff-d7e9e44fcb5fb1b98198415a3f78f167R1831] > [4] [https://github.com/apache/calcite/pull/1555] > [5] [https://github.com/apache/calcite/pull/1504] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3246) RelJsonReader throws NullPointerException while deserializing from JSON a call to a user-defined function (UDF)
[
https://issues.apache.org/jira/browse/CALCITE-3246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16988407#comment-16988407
]
Wang Yanlin commented on CALCITE-3246:
--
I rebase master, and create a new PR:
[https://github.com/apache/calcite/pull/1634]
Please help to review when you have time.
> RelJsonReader throws NullPointerException while deserializing from JSON a
> call to a user-defined function (UDF)
> ---
>
> Key: CALCITE-3246
> URL: https://issues.apache.org/jira/browse/CALCITE-3246
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Wang Yanlin
>Assignee: Chunwei Lei
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.22.0
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> when deserializing of logical rel with udf operator, NPE occurs.
> The exception stacktrace as follow.
> {code:java}
> java.lang.RuntimeException: java.lang.NullPointerException
> at org.apache.calcite.tools.Frameworks.withPrepare(Frameworks.java:181)
> at org.apache.calcite.tools.Frameworks.withPlanner(Frameworks.java:125)
> at org.apache.calcite.tools.Frameworks.withPlanner(Frameworks.java:143)
> at org.apache.calcite.plan.RelWriterTest.testUdf(RelWriterTest.java:598)
> 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
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> Caused by: java.lang.NullPointerException
> at java.util.Objects.requireNonNull(Objects.java:203)
> at org.apache.calcite.rex.RexCall.(RexCall.java:83)
> at org.apache.calcite.rex.RexBuilder.makeCall(RexBuilder.java:237)
> at org.apache.calcite.rel.externalize.RelJson.toRex(RelJson.java:485)
> at
> org.apache.calcite.rel.externalize.RelJsonReader$2.getExpressionList(RelJsonReader.java:204)
> at org.apache.calcite.rel.core.Project.(Project.java:100)
> at
> org.apache.calcite.rel.logical.LogicalProject.(LogicalProject.java:88)
> 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.rel.externalize.RelJsonReader.readRel(RelJsonReader.java:261)
> at
> org.apache.calcite.rel.externalize.RelJsonReader.readRels(RelJsonReader.java:91)
> at
> org.apache.calcite.rel.externalize.RelJsonReader.read(RelJsonReader.java:85)
> at
> org.apache.calcite.plan.RelWriterTest.lambda$testUdf$7(RelWriterTest.java:603)
> at
> org.apache.calcite.tools.Frameworks.lambda$withPlanner$0(Frameworks.java:130)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.perform(CalcitePrepareImpl.java:915)
> at
[jira] [Updated] (CALCITE-3564) Make operand type check accurate for some functions in validation phase
[
https://issues.apache.org/jira/browse/CALCITE-3564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Feng Zhu updated CALCITE-3564:
--
Description:
For some functions, it is too late to fail the query in runtime phase.
For example: _*RAND_INTEGER*_ adopts _*OperandTypes.or(OperandTypes.NUMERIC,
OperandTypes.NUMERIC_NUMERIC)*_
{code:java}
@Test public void test2() {
final String sql = "SELECT rand_integer(1.1, 2)";
CalciteAssert.that()
.query(sql)
.planContains("xyxyx")
.returns("EXPR$0={\"x\":1,\"y\":2.1}\n");
}{code}
We will get:
{code:java}
org.codehaus.commons.compiler.CompileException: Line 22, Column 100: No
applicable constructor/method found for actual parameters
"java.math.BigDecimal, int"; candidates are: "public int
org.apache.calcite.runtime.RandomFunction.randIntegerSeed(int, int)"
at org.codehaus.janino.UnitCompiler.compileError(UnitCompiler.java:12211)
at
org.codehaus.janino.UnitCompiler.findMostSpecificIInvocable(UnitCompiler.java:9263)
at org.codehaus.janino.UnitCompiler.findIMethod(UnitCompiler.java:9123){code}
> Make operand type check accurate for some functions in validation phase
> ---
>
> Key: CALCITE-3564
> URL: https://issues.apache.org/jira/browse/CALCITE-3564
> Project: Calcite
> Issue Type: Sub-task
>Reporter: Feng Zhu
>Priority: Major
>
> For some functions, it is too late to fail the query in runtime phase.
> For example: _*RAND_INTEGER*_ adopts _*OperandTypes.or(OperandTypes.NUMERIC,
> OperandTypes.NUMERIC_NUMERIC)*_
> {code:java}
> @Test public void test2() {
> final String sql = "SELECT rand_integer(1.1, 2)";
> CalciteAssert.that()
> .query(sql)
> .planContains("xyxyx")
> .returns("EXPR$0={\"x\":1,\"y\":2.1}\n");
> }{code}
> We will get:
> {code:java}
> org.codehaus.commons.compiler.CompileException: Line 22, Column 100: No
> applicable constructor/method found for actual parameters
> "java.math.BigDecimal, int"; candidates are: "public int
> org.apache.calcite.runtime.RandomFunction.randIntegerSeed(int, int)"
> at org.codehaus.janino.UnitCompiler.compileError(UnitCompiler.java:12211)
> at
> org.codehaus.janino.UnitCompiler.findMostSpecificIInvocable(UnitCompiler.java:9263)
> at org.codehaus.janino.UnitCompiler.findIMethod(UnitCompiler.java:9123){code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3477) Geospatial function (ST_MakePoint) with integer parameter fails
[
https://issues.apache.org/jira/browse/CALCITE-3477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Feng Zhu updated CALCITE-3477:
--
Summary: Geospatial function (ST_MakePoint) with integer parameter fails
(was: Decimal type should not be assigned from other types)
> Geospatial function (ST_MakePoint) with integer parameter fails
> ---
>
> Key: CALCITE-3477
> URL: https://issues.apache.org/jira/browse/CALCITE-3477
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Kirils Mensikovs
>Assignee: Feng Zhu
>Priority: Major
> Labels: geospatial, pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Geospatial function with integer parameter fails. The expected behavior is to
> cast automatically all number values to BigDecimal.
> {{Example: 'select ST_MAKEPOINT(1.0, 1)'}}
> Return:
> {code:java}
> Error: Error while executing SQL "select ST_MAKEPOINT(1.0, 1)": Error while
> compiling generated Java code:
> public org.apache.calcite.linq4j.Enumerable bind(final
> org.apache.calcite.DataContext root) {
> final org.apache.calcite.linq4j.Enumerable _inputEnumerable =
> org.apache.calcite.linq4j.Linq4j.asEnumerable(new Integer[] {
> 0});
> return new org.apache.calcite.linq4j.AbstractEnumerable(){
> public org.apache.calcite.linq4j.Enumerator enumerator() {
> return new org.apache.calcite.linq4j.Enumerator(){
> public final org.apache.calcite.linq4j.Enumerator inputEnumerator
> = _inputEnumerable.enumerator();
> public void reset() {
> inputEnumerator.reset();
> }
> public boolean moveNext() {
> return inputEnumerator.moveNext();
> }
> public void close() {
> inputEnumerator.close();
> }
> public Object current() {
> final java.math.BigDecimal v =
> $L4J$C$new_java_math_BigDecimal_1_0_;
> return org.apache.calcite.runtime.GeoFunctions.ST_MakePoint(v,
> 1);
> }
> static final java.math.BigDecimal
> $L4J$C$new_java_math_BigDecimal_1_0_ = new java.math.BigDecimal(
> "1.0");
> };
> }
> };
> }
> public Class getElementType() {
> return org.apache.calcite.runtime.GeoFunctions.Geom.class;
> } (state=,code=0)
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3549) Lex config for view expanding is not supported
[
https://issues.apache.org/jira/browse/CALCITE-3549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16988403#comment-16988403
]
Danny Chen commented on CALCITE-3549:
-
Thanks Julian for the feedback ~
What i'm curious about is what if the view lex convention is different with
current connection ? How could we use that view ? Should we also change the
connection lex to be same with the view one ? That is just not user-friendly, i
think.
> Lex config for view expanding is not supported
> --
>
> Key: CALCITE-3549
> URL: https://issues.apache.org/jira/browse/CALCITE-3549
> Project: Calcite
> Issue Type: Improvement
>Reporter: Jin Xing
>Priority: Major
> Labels: pull-request-available
> Time Spent: 50m
> Remaining Estimate: 0h
>
> UT as below:
> {code:java}
> // JdbcTest.java
> @Test public void testDEV() {
> modelWithView("select * from EMPLOYEES where deptno = 10", null)
> .with(Lex.JAVA)
> .query("select * from adhoc.V order by name desc")
> .returns("");
> }
> {code}
> Failed with
> {code:java}
> org.apache.calcite.sql.validate.SqlValidatorException: Column 'DEPTNO' not
> found in any table; did you mean 'deptno'?
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3246) RelJsonReader throws NullPointerException while deserializing from JSON a call to a user-defined function (UDF)
[
https://issues.apache.org/jira/browse/CALCITE-3246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16988394#comment-16988394
]
Chunwei Lei commented on CALCITE-3246:
--
[~yanlin-Lynn] , please open another PR for it.
> RelJsonReader throws NullPointerException while deserializing from JSON a
> call to a user-defined function (UDF)
> ---
>
> Key: CALCITE-3246
> URL: https://issues.apache.org/jira/browse/CALCITE-3246
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Wang Yanlin
>Assignee: Chunwei Lei
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.22.0
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> when deserializing of logical rel with udf operator, NPE occurs.
> The exception stacktrace as follow.
> {code:java}
> java.lang.RuntimeException: java.lang.NullPointerException
> at org.apache.calcite.tools.Frameworks.withPrepare(Frameworks.java:181)
> at org.apache.calcite.tools.Frameworks.withPlanner(Frameworks.java:125)
> at org.apache.calcite.tools.Frameworks.withPlanner(Frameworks.java:143)
> at org.apache.calcite.plan.RelWriterTest.testUdf(RelWriterTest.java:598)
> 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
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> Caused by: java.lang.NullPointerException
> at java.util.Objects.requireNonNull(Objects.java:203)
> at org.apache.calcite.rex.RexCall.(RexCall.java:83)
> at org.apache.calcite.rex.RexBuilder.makeCall(RexBuilder.java:237)
> at org.apache.calcite.rel.externalize.RelJson.toRex(RelJson.java:485)
> at
> org.apache.calcite.rel.externalize.RelJsonReader$2.getExpressionList(RelJsonReader.java:204)
> at org.apache.calcite.rel.core.Project.(Project.java:100)
> at
> org.apache.calcite.rel.logical.LogicalProject.(LogicalProject.java:88)
> 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.rel.externalize.RelJsonReader.readRel(RelJsonReader.java:261)
> at
> org.apache.calcite.rel.externalize.RelJsonReader.readRels(RelJsonReader.java:91)
> at
> org.apache.calcite.rel.externalize.RelJsonReader.read(RelJsonReader.java:85)
> at
> org.apache.calcite.plan.RelWriterTest.lambda$testUdf$7(RelWriterTest.java:603)
> at
> org.apache.calcite.tools.Frameworks.lambda$withPlanner$0(Frameworks.java:130)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.perform(CalcitePrepareImpl.java:915)
> at org.apache.calcite.tools.Frameworks.withPrepare(Frameworks.java:179)
> ... 25 more
> {code}
--
This message was
[jira] [Commented] (CALCITE-3460) Poor performance in RexReplacer for large queries
[
https://issues.apache.org/jira/browse/CALCITE-3460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16988390#comment-16988390
]
Chunwei Lei commented on CALCITE-3460:
--
Could you please add a test? We might get it into 1.22:).
> Poor performance in RexReplacer for large queries
> -
>
> Key: CALCITE-3460
> URL: https://issues.apache.org/jira/browse/CALCITE-3460
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Haisheng Yuan
>Priority: Major
> Labels: pull-request-available
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> We have queries that have tens of thousands of RexCalls.
> reducibleExps.indexOf(call) is an O(n) operation, which takes 50% of the
> running time, causing the query runs for ever until timed out.
> In RexShuttle, ImmutableList iterator creation in {{visitList}} takes another
> 5~7% of running time, and it is creating millions of temporary iterator
> object, not only time consuming, but also memory consuming.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-3569) IndexOutOfBoundsException when pushing simplifed filter to view
[
https://issues.apache.org/jira/browse/CALCITE-3569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16988385#comment-16988385
]
Chunwei Lei edited comment on CALCITE-3569 at 12/5/19 2:15 AM:
---
Fixed in
[11d7916e46509ef7bb0c0632667ec61f5c1008b1|https://github.com/apache/calcite/commit/11d7916e46509ef7bb0c0632667ec61f5c1008b1].
was (Author: chunwei lei):
Fixed in
[11d7916e46509ef7bb0c0632667ec61f5c1008b1|https://github.com/apache/calcite/commit/11d7916e46509ef7bb0c0632667ec61f5c1008b1]
> IndexOutOfBoundsException when pushing simplifed filter to view
> ---
>
> Key: CALCITE-3569
> URL: https://issues.apache.org/jira/browse/CALCITE-3569
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.21.0
>Reporter: Chunwei Lei
>Assignee: Chunwei Lei
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.22.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> It can be reproduced by the following test.
> {code:java}
> // MaterializationTest.java
> @Test public void testAggregate7() {
> try (TryThreadLocal.Memo ignored = Prepare.THREAD_TRIM.push(true)) {
> MaterializationService.setThreadLocal();
> CalciteAssert.that()
> .withMaterializations(
> HR_FKUK_MODEL,
> "m0",
> "select 11 as \"empno\", 22 as \"sal\", count(*) from \"emps\"
> group by 11, 22")
> .query(
> "select * from\n"
> + "(select 11 as \"empno\", 22 as \"sal\", count(*)\n"
> + "from \"emps\" group by 11, 22) tmp\n"
> + "where \"sal\" = 33")
> .enableMaterializations(true)
> .explainContains("EnumerableValues(tuples=[[]])");
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CALCITE-3569) IndexOutOfBoundsException when pushing simplifed filter to view
[
https://issues.apache.org/jira/browse/CALCITE-3569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chunwei Lei resolved CALCITE-3569.
--
Fix Version/s: 1.22.0
Resolution: Fixed
Fixed in
[11d7916e46509ef7bb0c0632667ec61f5c1008b1|https://github.com/apache/calcite/commit/11d7916e46509ef7bb0c0632667ec61f5c1008b1]
> IndexOutOfBoundsException when pushing simplifed filter to view
> ---
>
> Key: CALCITE-3569
> URL: https://issues.apache.org/jira/browse/CALCITE-3569
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.21.0
>Reporter: Chunwei Lei
>Assignee: Chunwei Lei
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.22.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> It can be reproduced by the following test.
> {code:java}
> // MaterializationTest.java
> @Test public void testAggregate7() {
> try (TryThreadLocal.Memo ignored = Prepare.THREAD_TRIM.push(true)) {
> MaterializationService.setThreadLocal();
> CalciteAssert.that()
> .withMaterializations(
> HR_FKUK_MODEL,
> "m0",
> "select 11 as \"empno\", 22 as \"sal\", count(*) from \"emps\"
> group by 11, 22")
> .query(
> "select * from\n"
> + "(select 11 as \"empno\", 22 as \"sal\", count(*)\n"
> + "from \"emps\" group by 11, 22) tmp\n"
> + "where \"sal\" = 33")
> .enableMaterializations(true)
> .explainContains("EnumerableValues(tuples=[[]])");
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3569) IndexOutOfBoundsException when pushing simplifed filter to view
[
https://issues.apache.org/jira/browse/CALCITE-3569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16988384#comment-16988384
]
Chunwei Lei commented on CALCITE-3569:
--
I happen to find it when I try to reproduce CALCITE-3538.
> IndexOutOfBoundsException when pushing simplifed filter to view
> ---
>
> Key: CALCITE-3569
> URL: https://issues.apache.org/jira/browse/CALCITE-3569
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.21.0
>Reporter: Chunwei Lei
>Assignee: Chunwei Lei
>Priority: Major
> Labels: pull-request-available
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> It can be reproduced by the following test.
> {code:java}
> // MaterializationTest.java
> @Test public void testAggregate7() {
> try (TryThreadLocal.Memo ignored = Prepare.THREAD_TRIM.push(true)) {
> MaterializationService.setThreadLocal();
> CalciteAssert.that()
> .withMaterializations(
> HR_FKUK_MODEL,
> "m0",
> "select 11 as \"empno\", 22 as \"sal\", count(*) from \"emps\"
> group by 11, 22")
> .query(
> "select * from\n"
> + "(select 11 as \"empno\", 22 as \"sal\", count(*)\n"
> + "from \"emps\" group by 11, 22) tmp\n"
> + "where \"sal\" = 33")
> .enableMaterializations(true)
> .explainContains("EnumerableValues(tuples=[[]])");
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3246) RelJsonReader throws NullPointerException while deserializing from JSON a call to a user-defined function (UDF)
[
https://issues.apache.org/jira/browse/CALCITE-3246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16988383#comment-16988383
]
Wang Yanlin commented on CALCITE-3246:
--
What to do next ? Should I create another PR or you can re-merge it.
> RelJsonReader throws NullPointerException while deserializing from JSON a
> call to a user-defined function (UDF)
> ---
>
> Key: CALCITE-3246
> URL: https://issues.apache.org/jira/browse/CALCITE-3246
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Wang Yanlin
>Assignee: Chunwei Lei
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.22.0
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> when deserializing of logical rel with udf operator, NPE occurs.
> The exception stacktrace as follow.
> {code:java}
> java.lang.RuntimeException: java.lang.NullPointerException
> at org.apache.calcite.tools.Frameworks.withPrepare(Frameworks.java:181)
> at org.apache.calcite.tools.Frameworks.withPlanner(Frameworks.java:125)
> at org.apache.calcite.tools.Frameworks.withPlanner(Frameworks.java:143)
> at org.apache.calcite.plan.RelWriterTest.testUdf(RelWriterTest.java:598)
> 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
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> Caused by: java.lang.NullPointerException
> at java.util.Objects.requireNonNull(Objects.java:203)
> at org.apache.calcite.rex.RexCall.(RexCall.java:83)
> at org.apache.calcite.rex.RexBuilder.makeCall(RexBuilder.java:237)
> at org.apache.calcite.rel.externalize.RelJson.toRex(RelJson.java:485)
> at
> org.apache.calcite.rel.externalize.RelJsonReader$2.getExpressionList(RelJsonReader.java:204)
> at org.apache.calcite.rel.core.Project.(Project.java:100)
> at
> org.apache.calcite.rel.logical.LogicalProject.(LogicalProject.java:88)
> 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.rel.externalize.RelJsonReader.readRel(RelJsonReader.java:261)
> at
> org.apache.calcite.rel.externalize.RelJsonReader.readRels(RelJsonReader.java:91)
> at
> org.apache.calcite.rel.externalize.RelJsonReader.read(RelJsonReader.java:85)
> at
> org.apache.calcite.plan.RelWriterTest.lambda$testUdf$7(RelWriterTest.java:603)
> at
> org.apache.calcite.tools.Frameworks.lambda$withPlanner$0(Frameworks.java:130)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.perform(CalcitePrepareImpl.java:915)
> at org.apache.calcite.tools.Frameworks.withPrepare(Frameworks.java:179)
> ... 25 more
> {code}
[jira] [Commented] (CALCITE-3550) Make SqlTypeAssignmentRules conversion mapping pluggable
[ https://issues.apache.org/jira/browse/CALCITE-3550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16988379#comment-16988379 ] Danny Chen commented on CALCITE-3550: - I agree, would just rename SqlTypeAssignmentRules to SqlTypeAssignmentRule because it actually not expect to be a public API, we alway use SqlTypeUtil#canCastFrom. > Make SqlTypeAssignmentRules conversion mapping pluggable > > > Key: CALCITE-3550 > URL: https://issues.apache.org/jira/browse/CALCITE-3550 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.21.0 >Reporter: Danny Chen >Priority: Major > Labels: pull-request-available > Fix For: 1.22.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > In CALCITE-2302, we introduce implicit type coercion for Calcite builtin > conversion behaviors, we also expand the conversion matrix to support more > type conversion compared to the old matrix [1], that means, we implement a > conversion matrix of our Calcite style. > As a library of other sql engines, i think we should make the conversion > matrix pluggable, so that each engine can customize if the conversion is > valid from a type to another. > We have made the TypeCoercion pluggable/customizable, so if this matrix is > also pluggable, then, the whole conversion behavior can be customized. > That would give the type conversion of Calcite a pretty good flexibility. > [1] > https://docs.google.com/spreadsheets/d/1GhleX5h5W8-kJKh7NMJ4vtoE78pwfaZRJl88ULX_MgU/edit?usp=sharing -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CALCITE-3567) UNNEST(RECORDTYPE(MAP)) not supported
[
https://issues.apache.org/jira/browse/CALCITE-3567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Sereda resolved CALCITE-3567.
Resolution: Fixed
Fixed in
[560d8951|https://github.com/apache/calcite/commit/560d8951279fddb305626fd3d188b88fbf88b1f9]
> UNNEST(RECORDTYPE(MAP)) not supported
> -
>
> Key: CALCITE-3567
> URL: https://issues.apache.org/jira/browse/CALCITE-3567
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.21.0
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Major
> Labels: pull-request-available
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> UNNEST(RECORDTYPE(ARRAY)) and UNNEST(RECORDTYPE(MULTISET)) works well, but
> UNNEST(RECORDTYPE(MAP)) is not supported.
> {code:java}
> // JdbcTest
> @Test public void testUnnestRecordType() {
> // unnest(RecordType(Array))
> CalciteAssert.that()
> .query("select * from unnest\n"
> + "(select t.x from (values array[10, 20], array[30, 40]) as
> t(x))\n"
> + " with ordinality as t(a, o)")
> .returnsUnordered("A=10; O=1", "A=20; O=2",
> "A=30; O=1", "A=40; O=2");
> // unnest(RecordType(Multiset))
> CalciteAssert.that()
> .query("select * from unnest\n"
> + "(select t.x from (values multiset[10, 20], array[30, 40]) as
> t(x))\n"
> + " with ordinality as t(a, o)")
> .returnsUnordered("A=10; O=1", "A=20; O=2",
> "A=30; O=1", "A=40; O=2");
> // unnest(RecordType(Map))
> CalciteAssert.that()
> .query("select * from unnest\n"
> + "(select t.x from (values map['a', 20, 'b', 30], map['c', 40])
> as t(x))\n"
> + " with ordinality as t(a, b, o)")
> .returnsUnordered("A=a; B=20; O=1", "A=B; B=30; O=2",
> "A=c; B=40; O=1");
> }
> {code}
> In the case, test for *unnest(RecordType(Array))* and
> *unnest(RecordType(Multiset))* success, but got exception for
> *unnest(RecordType(Map))*.
> For the first two test of *unnest(RecordType(Array))* and
> *unnest(RecordType(Multiset))*, the relnode tree with type is like this
> {noformat}
> EnumerableUncollect(withOrdinality=[true]), type = RecordType(INTEGER EXPR$0,
> INTEGER ORDINALITY)
> EnumerableUnion(all=[true]), type = RecordType(INTEGER ARRAY EXPR$0)
> EnumerableCalc(expr#0=[{inputs}], expr#1=[10], expr#2=[20],
> expr#3=[ARRAY($t1, $t2)], EXPR$0=[$t3]), type = RecordType(INTEGER ARRAY
> EXPR$0)
> EnumerableValues(tuples=[[{ 0 }]]), type = RecordType(INTEGER ZERO)
> EnumerableCalc(expr#0=[{inputs}], expr#1=[30], expr#2=[40],
> expr#3=[ARRAY($t1, $t2)], EXPR$0=[$t3]), type = RecordType(INTEGER ARRAY
> EXPR$0)
> EnumerableValues(tuples=[[{ 0 }]]), type = RecordType(INTEGER ZERO)
> EnumerableUncollect(withOrdinality=[true]), type = RecordType(INTEGER EXPR$0,
> INTEGER ORDINALITY)
> EnumerableUnion(all=[true]), type = RecordType(INTEGER ARRAY EXPR$0)
> EnumerableCalc(expr#0=[{inputs}], expr#1=[$SLICE($t0)], EXPR$0=[$t1]),
> type = RecordType(INTEGER MULTISET EXPR$0)
> EnumerableCollect(field=[EXPR$0]), type = RecordType(RecordType(INTEGER
> ROW_VALUE) MULTISET EXPR$0)
> EnumerableValues(tuples=[[{ 10 }, { 20 }]]), type =
> RecordType(INTEGER ROW_VALUE)
> EnumerableCalc(expr#0=[{inputs}], expr#1=[30], expr#2=[40],
> expr#3=[ARRAY($t1, $t2)], EXPR$0=[$t3]), type = RecordType(INTEGER ARRAY
> EXPR$0)
> EnumerableValues(tuples=[[{ 0 }]]), type = RecordType(INTEGER ZERO)
> {noformat}
> Part of the stacktrace of the exception is:
> {code:java}
> Cannot apply 'UNNEST' to arguments of type 'UNNEST( INTEGER) MAP X)>)'. Supported form(s): 'UNNEST()'
> 'UNNEST()'
> 'UNNEST()'
> UNNEST()
> 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:463)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:839)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:824)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:4905)
> at
> org.apache.calcite.sql.SqlCallBinding.newValidationSignatureError(SqlCallBinding.java:280)
> at
> org.apache.calcite.sql.type.CompositeOperandTypeChecker.checkOperandTypes(CompositeOperandTypeChecker.java:261)
> at
>
[jira] [Updated] (CALCITE-3567) UNNEST(RECORDTYPE(MAP)) not supported
[
https://issues.apache.org/jira/browse/CALCITE-3567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Sereda updated CALCITE-3567:
---
Affects Version/s: 1.21.0
> UNNEST(RECORDTYPE(MAP)) not supported
> -
>
> Key: CALCITE-3567
> URL: https://issues.apache.org/jira/browse/CALCITE-3567
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.21.0
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Major
> Labels: pull-request-available
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> UNNEST(RECORDTYPE(ARRAY)) and UNNEST(RECORDTYPE(MULTISET)) works well, but
> UNNEST(RECORDTYPE(MAP)) is not supported.
> {code:java}
> // JdbcTest
> @Test public void testUnnestRecordType() {
> // unnest(RecordType(Array))
> CalciteAssert.that()
> .query("select * from unnest\n"
> + "(select t.x from (values array[10, 20], array[30, 40]) as
> t(x))\n"
> + " with ordinality as t(a, o)")
> .returnsUnordered("A=10; O=1", "A=20; O=2",
> "A=30; O=1", "A=40; O=2");
> // unnest(RecordType(Multiset))
> CalciteAssert.that()
> .query("select * from unnest\n"
> + "(select t.x from (values multiset[10, 20], array[30, 40]) as
> t(x))\n"
> + " with ordinality as t(a, o)")
> .returnsUnordered("A=10; O=1", "A=20; O=2",
> "A=30; O=1", "A=40; O=2");
> // unnest(RecordType(Map))
> CalciteAssert.that()
> .query("select * from unnest\n"
> + "(select t.x from (values map['a', 20, 'b', 30], map['c', 40])
> as t(x))\n"
> + " with ordinality as t(a, b, o)")
> .returnsUnordered("A=a; B=20; O=1", "A=B; B=30; O=2",
> "A=c; B=40; O=1");
> }
> {code}
> In the case, test for *unnest(RecordType(Array))* and
> *unnest(RecordType(Multiset))* success, but got exception for
> *unnest(RecordType(Map))*.
> For the first two test of *unnest(RecordType(Array))* and
> *unnest(RecordType(Multiset))*, the relnode tree with type is like this
> {noformat}
> EnumerableUncollect(withOrdinality=[true]), type = RecordType(INTEGER EXPR$0,
> INTEGER ORDINALITY)
> EnumerableUnion(all=[true]), type = RecordType(INTEGER ARRAY EXPR$0)
> EnumerableCalc(expr#0=[{inputs}], expr#1=[10], expr#2=[20],
> expr#3=[ARRAY($t1, $t2)], EXPR$0=[$t3]), type = RecordType(INTEGER ARRAY
> EXPR$0)
> EnumerableValues(tuples=[[{ 0 }]]), type = RecordType(INTEGER ZERO)
> EnumerableCalc(expr#0=[{inputs}], expr#1=[30], expr#2=[40],
> expr#3=[ARRAY($t1, $t2)], EXPR$0=[$t3]), type = RecordType(INTEGER ARRAY
> EXPR$0)
> EnumerableValues(tuples=[[{ 0 }]]), type = RecordType(INTEGER ZERO)
> EnumerableUncollect(withOrdinality=[true]), type = RecordType(INTEGER EXPR$0,
> INTEGER ORDINALITY)
> EnumerableUnion(all=[true]), type = RecordType(INTEGER ARRAY EXPR$0)
> EnumerableCalc(expr#0=[{inputs}], expr#1=[$SLICE($t0)], EXPR$0=[$t1]),
> type = RecordType(INTEGER MULTISET EXPR$0)
> EnumerableCollect(field=[EXPR$0]), type = RecordType(RecordType(INTEGER
> ROW_VALUE) MULTISET EXPR$0)
> EnumerableValues(tuples=[[{ 10 }, { 20 }]]), type =
> RecordType(INTEGER ROW_VALUE)
> EnumerableCalc(expr#0=[{inputs}], expr#1=[30], expr#2=[40],
> expr#3=[ARRAY($t1, $t2)], EXPR$0=[$t3]), type = RecordType(INTEGER ARRAY
> EXPR$0)
> EnumerableValues(tuples=[[{ 0 }]]), type = RecordType(INTEGER ZERO)
> {noformat}
> Part of the stacktrace of the exception is:
> {code:java}
> Cannot apply 'UNNEST' to arguments of type 'UNNEST( INTEGER) MAP X)>)'. Supported form(s): 'UNNEST()'
> 'UNNEST()'
> 'UNNEST()'
> UNNEST()
> 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:463)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:839)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:824)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:4905)
> at
> org.apache.calcite.sql.SqlCallBinding.newValidationSignatureError(SqlCallBinding.java:280)
> at
> org.apache.calcite.sql.type.CompositeOperandTypeChecker.checkOperandTypes(CompositeOperandTypeChecker.java:261)
> at
> org.apache.calcite.sql.SqlOperator.checkOperandTypes(SqlOperator.java:668)
> at
> org.apache.calcite.sql.SqlOperator.validateOperands(SqlOperator.java:432)
> at
>
[jira] [Updated] (CALCITE-3567) UNNEST(RECORDTYPE(MAP)) not supported
[
https://issues.apache.org/jira/browse/CALCITE-3567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Sereda updated CALCITE-3567:
---
Component/s: core
> UNNEST(RECORDTYPE(MAP)) not supported
> -
>
> Key: CALCITE-3567
> URL: https://issues.apache.org/jira/browse/CALCITE-3567
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.21.0
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Major
> Labels: pull-request-available
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> UNNEST(RECORDTYPE(ARRAY)) and UNNEST(RECORDTYPE(MULTISET)) works well, but
> UNNEST(RECORDTYPE(MAP)) is not supported.
> {code:java}
> // JdbcTest
> @Test public void testUnnestRecordType() {
> // unnest(RecordType(Array))
> CalciteAssert.that()
> .query("select * from unnest\n"
> + "(select t.x from (values array[10, 20], array[30, 40]) as
> t(x))\n"
> + " with ordinality as t(a, o)")
> .returnsUnordered("A=10; O=1", "A=20; O=2",
> "A=30; O=1", "A=40; O=2");
> // unnest(RecordType(Multiset))
> CalciteAssert.that()
> .query("select * from unnest\n"
> + "(select t.x from (values multiset[10, 20], array[30, 40]) as
> t(x))\n"
> + " with ordinality as t(a, o)")
> .returnsUnordered("A=10; O=1", "A=20; O=2",
> "A=30; O=1", "A=40; O=2");
> // unnest(RecordType(Map))
> CalciteAssert.that()
> .query("select * from unnest\n"
> + "(select t.x from (values map['a', 20, 'b', 30], map['c', 40])
> as t(x))\n"
> + " with ordinality as t(a, b, o)")
> .returnsUnordered("A=a; B=20; O=1", "A=B; B=30; O=2",
> "A=c; B=40; O=1");
> }
> {code}
> In the case, test for *unnest(RecordType(Array))* and
> *unnest(RecordType(Multiset))* success, but got exception for
> *unnest(RecordType(Map))*.
> For the first two test of *unnest(RecordType(Array))* and
> *unnest(RecordType(Multiset))*, the relnode tree with type is like this
> {noformat}
> EnumerableUncollect(withOrdinality=[true]), type = RecordType(INTEGER EXPR$0,
> INTEGER ORDINALITY)
> EnumerableUnion(all=[true]), type = RecordType(INTEGER ARRAY EXPR$0)
> EnumerableCalc(expr#0=[{inputs}], expr#1=[10], expr#2=[20],
> expr#3=[ARRAY($t1, $t2)], EXPR$0=[$t3]), type = RecordType(INTEGER ARRAY
> EXPR$0)
> EnumerableValues(tuples=[[{ 0 }]]), type = RecordType(INTEGER ZERO)
> EnumerableCalc(expr#0=[{inputs}], expr#1=[30], expr#2=[40],
> expr#3=[ARRAY($t1, $t2)], EXPR$0=[$t3]), type = RecordType(INTEGER ARRAY
> EXPR$0)
> EnumerableValues(tuples=[[{ 0 }]]), type = RecordType(INTEGER ZERO)
> EnumerableUncollect(withOrdinality=[true]), type = RecordType(INTEGER EXPR$0,
> INTEGER ORDINALITY)
> EnumerableUnion(all=[true]), type = RecordType(INTEGER ARRAY EXPR$0)
> EnumerableCalc(expr#0=[{inputs}], expr#1=[$SLICE($t0)], EXPR$0=[$t1]),
> type = RecordType(INTEGER MULTISET EXPR$0)
> EnumerableCollect(field=[EXPR$0]), type = RecordType(RecordType(INTEGER
> ROW_VALUE) MULTISET EXPR$0)
> EnumerableValues(tuples=[[{ 10 }, { 20 }]]), type =
> RecordType(INTEGER ROW_VALUE)
> EnumerableCalc(expr#0=[{inputs}], expr#1=[30], expr#2=[40],
> expr#3=[ARRAY($t1, $t2)], EXPR$0=[$t3]), type = RecordType(INTEGER ARRAY
> EXPR$0)
> EnumerableValues(tuples=[[{ 0 }]]), type = RecordType(INTEGER ZERO)
> {noformat}
> Part of the stacktrace of the exception is:
> {code:java}
> Cannot apply 'UNNEST' to arguments of type 'UNNEST( INTEGER) MAP X)>)'. Supported form(s): 'UNNEST()'
> 'UNNEST()'
> 'UNNEST()'
> UNNEST()
> 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:463)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:839)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:824)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:4905)
> at
> org.apache.calcite.sql.SqlCallBinding.newValidationSignatureError(SqlCallBinding.java:280)
> at
> org.apache.calcite.sql.type.CompositeOperandTypeChecker.checkOperandTypes(CompositeOperandTypeChecker.java:261)
> at
> org.apache.calcite.sql.SqlOperator.checkOperandTypes(SqlOperator.java:668)
> at
> org.apache.calcite.sql.SqlOperator.validateOperands(SqlOperator.java:432)
> at
[jira] [Resolved] (CALCITE-3566) Support EnumerableIntersect and EnumerableMinus convert to Logical
[ https://issues.apache.org/jira/browse/CALCITE-3566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Sereda resolved CALCITE-3566. Resolution: Fixed Fixed in [e2f407f86b|https://github.com/apache/calcite/commit/e2f407f86b9b2d1878c405cf1779f41c40ee3188] > Support EnumerableIntersect and EnumerableMinus convert to Logical > -- > > Key: CALCITE-3566 > URL: https://issues.apache.org/jira/browse/CALCITE-3566 > Project: Calcite > Issue Type: Wish > Components: core >Affects Versions: 1.21.0 >Reporter: xzh_dz >Priority: Minor > Labels: pull-request-available > Time Spent: 50m > Remaining Estimate: 0h > > In ToLogicalConverter, EnumerableIntersect and EnumerableMinus can not > convert to Logical currently, this PR supports this transformation. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-3566) Support EnumerableIntersect and EnumerableMinus convert to Logical
[ https://issues.apache.org/jira/browse/CALCITE-3566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Sereda updated CALCITE-3566: --- Component/s: core > Support EnumerableIntersect and EnumerableMinus convert to Logical > -- > > Key: CALCITE-3566 > URL: https://issues.apache.org/jira/browse/CALCITE-3566 > Project: Calcite > Issue Type: Wish > Components: core >Affects Versions: 1.21.0 >Reporter: xzh_dz >Priority: Minor > Labels: pull-request-available > Time Spent: 50m > Remaining Estimate: 0h > > In ToLogicalConverter, EnumerableIntersect and EnumerableMinus can not > convert to Logical currently, this PR supports this transformation. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-3566) Support EnumerableIntersect and EnumerableMinus convert to Logical
[ https://issues.apache.org/jira/browse/CALCITE-3566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Sereda updated CALCITE-3566: --- Affects Version/s: 1.21.0 > Support EnumerableIntersect and EnumerableMinus convert to Logical > -- > > Key: CALCITE-3566 > URL: https://issues.apache.org/jira/browse/CALCITE-3566 > Project: Calcite > Issue Type: Wish >Affects Versions: 1.21.0 >Reporter: xzh_dz >Priority: Minor > Labels: pull-request-available > Time Spent: 50m > Remaining Estimate: 0h > > In ToLogicalConverter, EnumerableIntersect and EnumerableMinus can not > convert to Logical currently, this PR supports this transformation. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-3560) Additional calcite.util.Source implementation for generic text source (eg. CharSource)
[
https://issues.apache.org/jira/browse/CALCITE-3560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Sereda updated CALCITE-3560:
---
Labels: pull-requests-available (was: pull-request-available)
> Additional calcite.util.Source implementation for generic text source (eg.
> CharSource)
> --
>
> Key: CALCITE-3560
> URL: https://issues.apache.org/jira/browse/CALCITE-3560
> Project: Calcite
> Issue Type: Improvement
> Components: csv-adapter, file-adapter
>Affects Versions: 1.21.0
>Reporter: Andrei Sereda
>Assignee: Andrei Sereda
>Priority: Major
> Labels: pull-requests-available
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Currently calcite {{calcite.util.Source}} interface can be built only from
> [File|https://docs.oracle.com/javase/8/docs/api/java/io/File.html] or
> [URL|https://docs.oracle.com/javase/8/docs/api/java/net/URL.html]. This
> forces data to be stored on disk or accessed remotely using URL api.
> This proposal adds another Source implementation on the top of
> [CharSource|https://guava.dev/releases/19.0/api/docs/com/google/common/io/CharSource.html]
> so calcite adapters can operate on in-memory elements like String or generic
> text sources.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CALCITE-3285) EnumerableMergeJoin should support non-equi join conditions
[ https://issues.apache.org/jira/browse/CALCITE-3285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Haisheng Yuan resolved CALCITE-3285. Fix Version/s: 1.22.0 Resolution: Fixed Fixed in https://github.com/apache/calcite/commit/a0931b784c60683eb6845b3087d79f33160fc868. Thanks for the PR, [~jinxing6...@126.com]! > EnumerableMergeJoin should support non-equi join conditions > --- > > Key: CALCITE-3285 > URL: https://issues.apache.org/jira/browse/CALCITE-3285 > Project: Calcite > Issue Type: Improvement >Reporter: Haisheng Yuan >Assignee: Jin Xing >Priority: Major > Labels: pull-request-available > Fix For: 1.22.0 > > Time Spent: 2h 50m > Remaining Estimate: 0h > > Calcite should be able to generate EnumerableMergeJoin with non-equi join > conditions, as long as there are equi-join conditions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3550) Make SqlTypeAssignmentRules conversion mapping pluggable
[
https://issues.apache.org/jira/browse/CALCITE-3550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16988264#comment-16988264
]
Julian Hyde commented on CALCITE-3550:
--
Can we adopt the naming convention that plural class names are only for
utilities? I know SqlTypeAssignmentRules doesn't quite adhere to that (though
it has some static methods), but new classes should. Also, I think the new base
class should be an interface.
I agree we don't need {{synchronized}} any more. Perhaps Guava's
{{Suppliers.memoize}} will help with race conditions.
I agree that {{ThreadLocal}} is sufficient. It will avoid changing lots of
code. Mention the ThreadLocal in the SqlValidator javadoc, though.
> Make SqlTypeAssignmentRules conversion mapping pluggable
>
>
> Key: CALCITE-3550
> URL: https://issues.apache.org/jira/browse/CALCITE-3550
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.21.0
>Reporter: Danny Chen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.22.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> In CALCITE-2302, we introduce implicit type coercion for Calcite builtin
> conversion behaviors, we also expand the conversion matrix to support more
> type conversion compared to the old matrix [1], that means, we implement a
> conversion matrix of our Calcite style.
> As a library of other sql engines, i think we should make the conversion
> matrix pluggable, so that each engine can customize if the conversion is
> valid from a type to another.
> We have made the TypeCoercion pluggable/customizable, so if this matrix is
> also pluggable, then, the whole conversion behavior can be customized.
> That would give the type conversion of Calcite a pretty good flexibility.
> [1]
> https://docs.google.com/spreadsheets/d/1GhleX5h5W8-kJKh7NMJ4vtoE78pwfaZRJl88ULX_MgU/edit?usp=sharing
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-2223) ProjectMergeRule is infinitely matched when is applied after ProjectReduceExpressionsRule
[
https://issues.apache.org/jira/browse/CALCITE-2223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16988262#comment-16988262
]
Xiening Dai commented on CALCITE-2223:
--
I am not able to reproduce this on the latest master.
> ProjectMergeRule is infinitely matched when is applied after
> ProjectReduceExpressionsRule
> -
>
> Key: CALCITE-2223
> URL: https://issues.apache.org/jira/browse/CALCITE-2223
> Project: Calcite
> Issue Type: Bug
>Reporter: Vova Vysotskyi
>Priority: Critical
> Labels: pull-request-available
> Attachments:
> TestLimitWithExchanges_testPushLimitPastUnionExchange.png, heap_overview.png,
> provenance_contents.png
>
>
> For queries like this:
> {code:sql}
> select t1.f from (select cast(f as int) f, f from (select cast(f as int) f
> from (values('1')) t(f))) as t1
> {code}
> OOM is thrown when {{ProjectMergeRule}} is applied before applying
> {{ProjectReduceExpressionsRule}} in VolcanoPlanner.
> A simple test to reproduce this issue (in {{RelOptRulesTest}}):
> {code:java}
> @Test public void testOomProjectMergeRule() {
> RelBuilder relBuilder =
> RelBuilder.create(RelBuilderTest.config().build());
> RelNode relNode = relBuilder
> .values(new String[]{"f"}, "1")
> .project(
> relBuilder.alias(
> relBuilder.cast(relBuilder.field(0), SqlTypeName.INTEGER),
> "f"))
> .project(
> relBuilder.alias(
> relBuilder.cast(relBuilder.field(0), SqlTypeName.INTEGER),
> "f0"),
> relBuilder.alias(relBuilder.field(0), "f"))
> .project(
> relBuilder.alias(relBuilder.field(0), "f"))
> .build();
> RelOptPlanner planner = relNode.getCluster().getPlanner();
> RuleSet ruleSet =
> RuleSets.ofList(
> ReduceExpressionsRule.PROJECT_INSTANCE,
> new ProjectMergeRuleWithLongerName(),
> EnumerableRules.ENUMERABLE_PROJECT_RULE,
> EnumerableRules.ENUMERABLE_VALUES_RULE);
> Program program = Programs.of(ruleSet);
> RelTraitSet toTraits =
> relNode.getCluster().traitSet()
> .replace(0, EnumerableConvention.INSTANCE);
> RelNode output = program.run(planner, relNode, toTraits,
> ImmutableList.of(),
> ImmutableList.of());
> // check for output
> }
> /**
>* ProjectMergeRule inheritor which has
>* class name greater than ProjectReduceExpressionsRule class name
> (String.compareTo()).
>*
>* It is needed for RuleQueue.popMatch() method
>* to apply this rule before ProjectReduceExpressionsRule.
>*/
> private static class ProjectMergeRuleWithLongerName extends
> ProjectMergeRule {
> public ProjectMergeRuleWithLongerName() {
> super(true, RelFactories.LOGICAL_BUILDER);
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3554) NullPointerException when deserializing LogicalTableFunctionScan from json
[
https://issues.apache.org/jira/browse/CALCITE-3554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16988260#comment-16988260
]
Julian Hyde commented on CALCITE-3554:
--
Even if CALCITE-3246 were solved, in general you can't serialize a function
object even if you know its class name. It may not have a no-arguments public
constructor. Or it may not have been created using that constructor. So I'd say
that use case is 'won't fix'.
> NullPointerException when deserializing LogicalTableFunctionScan from json
> --
>
> Key: CALCITE-3554
> URL: https://issues.apache.org/jira/browse/CALCITE-3554
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Priority: Major
>
> Run this test case in *RelWriterTest*
> {code:java}
> @Test public void testTableFunctionScan() {
> final RelBuilder builder =
> RelBuilder.create(RelBuilderTest.config().build());
> final SqlOperator dedupFunction =
> new MockSqlOperatorTable.DedupFunction();
> RelNode rel = builder.scan("EMP")
> .scan("DEPT")
> .functionScan(dedupFunction, 2, builder.cursor(2, 0),
> builder.cursor(2, 1))
> .build();
> RelJsonWriter jsonWriter = new RelJsonWriter();
> rel.explain(jsonWriter);
> String relJson = jsonWriter.asString();
> System.out.println(RelOptUtil.toString(rel));
> System.out.println(relJson);
> String s = deserializeAndDumpToTextFormat(getSchema(rel), relJson);
> final String expected = "xxx";
> assertThat(s, isLinux(expected));
> }
> {code}
> Got
> {code:java}
> Caused by: java.lang.NullPointerException: operator
> at java.util.Objects.requireNonNull(Objects.java:228)
> at org.apache.calcite.rex.RexCall.(RexCall.java:83)
> at org.apache.calcite.rex.RexBuilder.makeCall(RexBuilder.java:237)
> at org.apache.calcite.rel.externalize.RelJson.toRex(RelJson.java:502)
> at
> org.apache.calcite.rel.externalize.RelJsonReader$2.getExpression(RelJsonReader.java:132)
> at
> org.apache.calcite.rel.core.TableFunctionScan.(TableFunctionScan.java:97)
> at
> org.apache.calcite.rel.logical.LogicalTableFunctionScan.(LogicalTableFunctionScan.java:81)
> 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.rel.externalize.RelJsonReader.readRel(RelJsonReader.java:261)
> at
> org.apache.calcite.rel.externalize.RelJsonReader.readRels(RelJsonReader.java:91)
> at
> org.apache.calcite.rel.externalize.RelJsonReader.read(RelJsonReader.java:85)
> at
> org.apache.calcite.plan.RelWriterTest.lambda$deserializeAndDumpToTextFormat$6(RelWriterTest.java:793)
> at
> org.apache.calcite.tools.Frameworks.lambda$withPlanner$0(Frameworks.java:130)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.perform(CalcitePrepareImpl.java:915)
> at org.apache.calcite.tools.Frameworks.withPrepare(Frameworks.java:179)
> ... 26 more
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-2772) Support varargs for user-defined functions (UDFs)
[
https://issues.apache.org/jira/browse/CALCITE-2772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16988259#comment-16988259
]
Rui Wang commented on CALCITE-2772:
---
Hello, [~pzw2018], Calcite is releasing 1.22.0. As you have a pending PR
already, would you consider to improve it to make it possibly released in
1.22.0. varargs support in UDF is indeed useful.
> Support varargs for user-defined functions (UDFs)
> -
>
> Key: CALCITE-2772
> URL: https://issues.apache.org/jira/browse/CALCITE-2772
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: pengzhiwei
>Assignee: pengzhiwei
>Priority: Major
> Labels: pull-request-available
> Attachments: support_varargs_udf.patch
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> Support varargs for user-defined functions as the case followed:
> {code:java}
> public class ConcatWs {
> public String eval(String sep, String... strs) {...}
> }{code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3246) RelJsonReader throws NullPointerException while deserializing from JSON a call to a user-defined function (UDF)
[
https://issues.apache.org/jira/browse/CALCITE-3246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16988258#comment-16988258
]
Julian Hyde commented on CALCITE-3246:
--
Since we already deserialize based on class name, this change can't make things
worse.
> RelJsonReader throws NullPointerException while deserializing from JSON a
> call to a user-defined function (UDF)
> ---
>
> Key: CALCITE-3246
> URL: https://issues.apache.org/jira/browse/CALCITE-3246
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Wang Yanlin
>Assignee: Chunwei Lei
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.22.0
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> when deserializing of logical rel with udf operator, NPE occurs.
> The exception stacktrace as follow.
> {code:java}
> java.lang.RuntimeException: java.lang.NullPointerException
> at org.apache.calcite.tools.Frameworks.withPrepare(Frameworks.java:181)
> at org.apache.calcite.tools.Frameworks.withPlanner(Frameworks.java:125)
> at org.apache.calcite.tools.Frameworks.withPlanner(Frameworks.java:143)
> at org.apache.calcite.plan.RelWriterTest.testUdf(RelWriterTest.java:598)
> 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
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> Caused by: java.lang.NullPointerException
> at java.util.Objects.requireNonNull(Objects.java:203)
> at org.apache.calcite.rex.RexCall.(RexCall.java:83)
> at org.apache.calcite.rex.RexBuilder.makeCall(RexBuilder.java:237)
> at org.apache.calcite.rel.externalize.RelJson.toRex(RelJson.java:485)
> at
> org.apache.calcite.rel.externalize.RelJsonReader$2.getExpressionList(RelJsonReader.java:204)
> at org.apache.calcite.rel.core.Project.(Project.java:100)
> at
> org.apache.calcite.rel.logical.LogicalProject.(LogicalProject.java:88)
> 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.rel.externalize.RelJsonReader.readRel(RelJsonReader.java:261)
> at
> org.apache.calcite.rel.externalize.RelJsonReader.readRels(RelJsonReader.java:91)
> at
> org.apache.calcite.rel.externalize.RelJsonReader.read(RelJsonReader.java:85)
> at
> org.apache.calcite.plan.RelWriterTest.lambda$testUdf$7(RelWriterTest.java:603)
> at
> org.apache.calcite.tools.Frameworks.lambda$withPlanner$0(Frameworks.java:130)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.perform(CalcitePrepareImpl.java:915)
> at org.apache.calcite.tools.Frameworks.withPrepare(Frameworks.java:179)
> ...
[jira] [Commented] (CALCITE-3556) Add TO_NUMBER function
[
https://issues.apache.org/jira/browse/CALCITE-3556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16988248#comment-16988248
]
Julian Hyde commented on CALCITE-3556:
--
I saw you closed the PR. You can leave it open, just add commits.
> Add TO_NUMBER function
> --
>
> Key: CALCITE-3556
> URL: https://issues.apache.org/jira/browse/CALCITE-3556
> Project: Calcite
> Issue Type: New Feature
>Reporter: vaibhav jain
>Priority: Major
> Labels: pull-request-available
> Time Spent: 40m
> Remaining Estimate: 0h
>
> TO_NUMBER error:
> No match found for function signature TO_NUMBER(, )
> Example :
> SELECT TO_NUMBER ('1234', '')
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-2449) RexSimplify overhaul
[
https://issues.apache.org/jira/browse/CALCITE-2449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16988247#comment-16988247
]
Rui Wang commented on CALCITE-2449:
---
[~vladimirsitnikov]
Is there some work of Jira that I can help with? It seems a big JIRA.
> RexSimplify overhaul
>
>
> Key: CALCITE-2449
> URL: https://issues.apache.org/jira/browse/CALCITE-2449
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.17.0
>Reporter: Vladimir Sitnikov
>Assignee: Vladimir Sitnikov
>Priority: Major
>
> I would like to update \{{RexSimplify}} as follows:
> 1) Avoid multiple passes over the same expressions. Current logic calls
> "simplify" in multiple places, and it might cause simplification of the same
> tree again and again.
> 2) I would like to rework \{{unknownAsFalse}} into support for \{{IS TRUE}}.
> Current support for \{{unknownAsFalse}} is hard to follow, and it looks like
> IS_TRUE(expr) allows for the same optimizations. In other words,
> "unknownAsFalse" would become a silent adding of IS_TRUE on top of the input
> expression. Then rules like \{{OR(x, y) IS TRUE ==> x IS TRUE or y IS TRUE}}
> would push \{{IS TRUE}} downstream.
> 3) I would like to "reorder" predicates in a defined order (e.g. rewrite
> \{{5=x ==> x=5}} or \{{(x=1 or y=2) and (z=3)}} ==> \{{(z=3) and (x=1 or
> y=2)}}. It looks like adding \{{int nodeCount;}} to \{{RexNode}} would be
> helpful to rank rex nodes.
> 4) There are other bugs identified by expression fuzzer (like {{and(null,
> not(null))}} conversion to true and so on)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3272) TUMBLE Table-valued Function
[ https://issues.apache.org/jira/browse/CALCITE-3272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16988245#comment-16988245 ] Julian Hyde commented on CALCITE-3272: -- I see you added some commits on Nov 25. I'll try to find time to review again. > TUMBLE Table-valued Function > > > Key: CALCITE-3272 > URL: https://issues.apache.org/jira/browse/CALCITE-3272 > Project: Calcite > Issue Type: Sub-task >Reporter: Rui Wang >Assignee: Rui Wang >Priority: Major > Labels: pull-request-available > Fix For: 1.22.0 > > Time Spent: 4h 10m > Remaining Estimate: 0h > > Define a builtin TVF: Tumble (data , timecol , dur, [ offset ]) > The return value of Tumble is a relation that includes all columns of data as > well as additional event time columns window_start and window_end. > Examples of TUMBLE TVF are (from https://s.apache.org/streaming-beam-sql ): > 8:21> SELECT * FROM Bid; > -- > | bidtime | price | item | > -- > | 8:07| $2| A| > | 8:11| $3| B| > | 8:05| $4| C| > | 8:09| $5| D| > | 8:13| $1| E| > | 8:17| $6| F| > -- > 8:21> SELECT * > FROM TABLE Tumble ( > data=> TABLE Bid , > timecol => DESCRIPTOR ( bidtime ) , > dur => INTERVAL '10' MINUTES , > offset => INTERVAL '0' MINUTES ); > -- > | window_start | window_end | bidtime | price | item | > -- > | 8:00 | 8:10 | 8:07| $2| A| > | 8:10 | 8:20 | 8:11| $3| B| > | 8:00 | 8:10 | 8:05| $4| C| > | 8:00 | 8:10 | 8:09| $5| D| > | 8:10 | 8:20 | 8:13| $1| E| > | 8:10 | 8:20 | 8:17| $6| F| > -- > 8:21> SELECT MAX ( window_start ) , window_end , SUM ( price ) > FROM TABLE Tumble ( > data=> TABLE ( Bid ) , > timecol => DESCRIPTOR ( bidtime ) , > dur => INTERVAL '10 ' MINUTES ) > GROUP BY wend; > - > | window_start | window_end | price | > - > | 8:00 | 8:10 | $11 | > | 8:10 | 8:20 | $10 | > - -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3549) Lex config for view expanding is not supported
[
https://issues.apache.org/jira/browse/CALCITE-3549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16988239#comment-16988239
]
Julian Hyde commented on CALCITE-3549:
--
Imagine that two people are connected to the same schema in which a view is
defined, and their connections have different Lex conventions. Should each
person expand the view in their connection's Lex convention? No.
The context for parsing the view should be fixed. That means defined in the
schema, falling back to fixed defaults, not inherited from the connection using
it. This applies to the SQL dialect (lex convention) but also to the path used
to resolve functions used in the view.
> Lex config for view expanding is not supported
> --
>
> Key: CALCITE-3549
> URL: https://issues.apache.org/jira/browse/CALCITE-3549
> Project: Calcite
> Issue Type: Improvement
>Reporter: Jin Xing
>Priority: Major
> Labels: pull-request-available
> Time Spent: 50m
> Remaining Estimate: 0h
>
> UT as below:
> {code:java}
> // JdbcTest.java
> @Test public void testDEV() {
> modelWithView("select * from EMPLOYEES where deptno = 10", null)
> .with(Lex.JAVA)
> .query("select * from adhoc.V order by name desc")
> .returns("");
> }
> {code}
> Failed with
> {code:java}
> org.apache.calcite.sql.validate.SqlValidatorException: Column 'DEPTNO' not
> found in any table; did you mean 'deptno'?
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3558) Columns reordering doesn't work in SplunkPushDownRule
[
https://issues.apache.org/jira/browse/CALCITE-3558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16988233#comment-16988233
]
Julian Hyde commented on CALCITE-3558:
--
Definitely need a test case.
If you need to maintain an ordinal in a for loop, use {{Ord.zip}}: {{for
(Ord rn : Ord.zip(topProj.getProjects())}}.
> Columns reordering doesn't work in SplunkPushDownRule
> -
>
> Key: CALCITE-3558
> URL: https://issues.apache.org/jira/browse/CALCITE-3558
> Project: Calcite
> Issue Type: Bug
> Components: splunk
>Affects Versions: 1.21.0
> Environment: Splunk 7.3+
>Reporter: Shawn Chen
>Assignee: Shawn Chen
>Priority: Major
> Labels: pull-request-available
> Fix For: next
>
> Original Estimate: 6h
> Time Spent: 6h
> Remaining Estimate: 0h
>
> The indexing variable i doesn't increase per loop between line 233 to 246 in
> SplunkPushDownRule.java.
> This bug causes column reordering nonfunctional.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3569) IndexOutOfBoundsException when pushing simplifed filter to view
[
https://issues.apache.org/jira/browse/CALCITE-3569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16988176#comment-16988176
]
Haisheng Yuan commented on CALCITE-3569:
Just curious, How did you find it?
> IndexOutOfBoundsException when pushing simplifed filter to view
> ---
>
> Key: CALCITE-3569
> URL: https://issues.apache.org/jira/browse/CALCITE-3569
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.21.0
>Reporter: Chunwei Lei
>Assignee: Chunwei Lei
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It can be reproduced by the following test.
> {code:java}
> // MaterializationTest.java
> @Test public void testAggregate7() {
> try (TryThreadLocal.Memo ignored = Prepare.THREAD_TRIM.push(true)) {
> MaterializationService.setThreadLocal();
> CalciteAssert.that()
> .withMaterializations(
> HR_FKUK_MODEL,
> "m0",
> "select 11 as \"empno\", 22 as \"sal\", count(*) from \"emps\"
> group by 11, 22")
> .query(
> "select * from\n"
> + "(select 11 as \"empno\", 22 as \"sal\", count(*)\n"
> + "from \"emps\" group by 11, 22) tmp\n"
> + "where \"sal\" = 33")
> .enableMaterializations(true)
> .explainContains("EnumerableValues(tuples=[[]])");
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3478) Reconstructure of materialized view tests.
[ https://issues.apache.org/jira/browse/CALCITE-3478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16988178#comment-16988178 ] Julian Hyde commented on CALCITE-3478: -- Can you change Jira summary and commit message to "Restructure tests for materialized views". "Reconstructure" is not a word. > Reconstructure of materialized view tests. > -- > > Key: CALCITE-3478 > URL: https://issues.apache.org/jira/browse/CALCITE-3478 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jin Xing >Assignee: Jin Xing >Priority: Major > Labels: pull-request-available > Time Spent: 1h 20m > Remaining Estimate: 0h > > h2. *Motivation* > Currently there are two strategies for materialized view matching: > *strategy-1*. Substitution based (SubstitutionVisitor.java) [1] > *strategy-2*. Plan structural information based > (AbstractMaterializedViewRule.java) [2] > The two strategies are controlled by a single connection config of > "materializationsEnabled". Calcite will apply strategy-1 firstly and then > strategy-2. > The two strategies are tested in a single integration test called > MaterializationTest.java, > As a result we cannot run tests separately for a single strategy, which > leads to: > # When some new matching patterns are supported by strategy-1, we might need > to update the old result plan, which was previously matched and generated by > stragegy-2, e.g. [3], and corresponding testing pattern for stragegy-2 will > be lost. > # Some test failures are even hidden, e.g. > MaterializationTest#testJoinMaterialization2 should but failed to be > supported by stragegy-2. However strategy-1 lets the test passed. > # Hard to test internals for SubstutionVisitor.java, e.g. [4] has to > struggle and create a unit test > Of course we can add more system config or connection config just for testing > and circle around some of the dilemmas I mentioned above. But it will make > the code messy. Materialized view matching strategies are so important and > worth a through unit test and to be kept clean. > Additionally, this JIRA targets to clean the code of > MaterializationTest.java. As more and more fixes get applied, this Java file > tends to be messy: > # Helping methods and testing methods are mixed without good order. > # Lots of methods called checkMaterialize. We need to sort it out if there's > need to add more params, e.g. [5] > # Some tests are not concise enough, e.g. testJoinMaterialization9 > h2. *Approach* > 1. Create unit test MaterializedViewSubstitutionVisitorTest to test strategy-1 > 2. Create unit test MaterializedViewRelOptRulesTest to test strategy-2 > 3. Move tests from MaterializationTest to unit tests correspondingly, and > keep MaterializationTest for integration tests. > > [1] > [https://calcite.apache.org/docs/materialized_views.html#substitution-via-rules-transformation] > [2] > [https://calcite.apache.org/docs/materialized_views.html#rewriting-using-plan-structural-information] > [3] > [https://github.com/apache/calcite/pull/1451/files#diff-d7e9e44fcb5fb1b98198415a3f78f167R1831] > [4] [https://github.com/apache/calcite/pull/1555] > [5] [https://github.com/apache/calcite/pull/1504] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-3561) Implement Uncollect relational operator in Interpreter (for SQL queries that use UNNEST)
[
https://issues.apache.org/jira/browse/CALCITE-3561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-3561:
-
Summary: Implement Uncollect relational operator in Interpreter (for SQL
queries that use UNNEST) (was: Support using unnest in Interpreter)
> Implement Uncollect relational operator in Interpreter (for SQL queries that
> use UNNEST)
>
>
> Key: CALCITE-3561
> URL: https://issues.apache.org/jira/browse/CALCITE-3561
> Project: Calcite
> Issue Type: Improvement
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Using unnest in Interpreter will cause exception,
> {code:java}
> // InterpreterTest
> @Test public void testInterpretUnnest() throws Exception {
> final String sql = "select * from unnest(multiset[1, 2])";
> sql(sql).returnsRows("[1]", "[2]");
> }
> {code}
> got
> {code:java}
> java.lang.AssertionError: interpreter: no implementation for class
> org.apache.calcite.rel.core.Uncollect
> at
> org.apache.calcite.interpreter.Interpreter$CompilerImpl.visit(Interpreter.java:463)
> at
> org.apache.calcite.interpreter.Nodes$CoreCompiler.visit(Nodes.java:44)
> at org.apache.calcite.rel.SingleRel.childrenAccept(SingleRel.java:72)
> at
> org.apache.calcite.interpreter.Interpreter$CompilerImpl.visit(Interpreter.java:450)
> at
> org.apache.calcite.interpreter.Nodes$CoreCompiler.visit(Nodes.java:44)
> at
> org.apache.calcite.interpreter.Interpreter$CompilerImpl.visitRoot(Interpreter.java:408)
> at
> org.apache.calcite.interpreter.Interpreter.(Interpreter.java:89)
> at
> org.apache.calcite.test.InterpreterTest$Sql.returnsRows(InterpreterTest.java:121)
> at
> org.apache.calcite.test.InterpreterTest$Sql.returnsRows(InterpreterTest.java:105)
> at
> org.apache.calcite.test.InterpreterTest.testInterpretUnnest(InterpreterTest.java:446)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> {code}
> Add support to use unnest in Interpreter.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3562) Unify function's operands type check logic in validation and behavior in runtime
[
https://issues.apache.org/jira/browse/CALCITE-3562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16988170#comment-16988170
]
Julian Hyde commented on CALCITE-3562:
--
Too long for me to read all of this, but I think you are confusing user-defined
functions and internal functions.
* User-defined functions have argument types such as BigDecimal, Timestamp,
Date. They aim to be convenient, not necessarily performant.
* Internal functions, which occur in {{class SqlFunctions}}, and are only used
by code generation, and operate on internal types. DATE is represented as
{{int}}. TIMESTAMP is represented as {{long}}. DECIMAL is represented as
{{long}}.
> Unify function's operands type check logic in validation and behavior in
> runtime
>
>
> Key: CALCITE-3562
> URL: https://issues.apache.org/jira/browse/CALCITE-3562
> Project: Calcite
> Issue Type: Task
> Components: core
>Reporter: Feng Zhu
>Priority: Major
>
> Current now, there are many issues caused by inconsistency between validator
> and runtime phase. To summarize:
> (1)Validation phase allows a wide range of operand types, but the runtime
> implementation does not cover all cases.
> For example, _*SqlFunction(MOD)*_ adopts
> _*OperandTypes.EXACT_NUMERIC_EXACT_NUMERIC*_.
> {code:java}
> @Test public void test0() {
> final String sql = "SELECT mod(12.5, cast(1 as bigint))";
> CalciteAssert.that()
> .query(sql)
> .returns("EXPR$0=0.5\n");
> }{code}
> We will get:
> {code:java}
> java.lang.RuntimeException: while resolving method 'mod[class
> java.math.BigDecimal, long]' in class class
> org.apache.calcite.runtime.SqlFunctions
> at org.apache.calcite.linq4j.tree.Types.lookupMethod(Types.java:323)
> at org.apache.calcite.linq4j.tree.Expressions.call(Expressions.java:445)
> at
> org.apache.calcite.adapter.enumerable.RexImpTable$MethodNameImplementor.implement(RexImpTable.java:2253)
> at
> org.apache.calcite.adapter.enumerable.RexImpTable.implementCall(RexImpTable.java:1195){code}
>
> (2)Type is assignable conceptually, but in the runtime phase, explicite cast
> is still required.
> For example, according to _*SqlTypeAssignmentRules*_,
> *_ST_MakePoint(Decimal, Decimal)_* also accepts operands with (_Integer_,
> _Decimal_) types, because Decimal is assignable from Integer.
> {code:java}
> @Test public void test1() {
> final String sql = "SELECT ST_MakePoint(1, 2.1)";
> CalciteAssert.that()
> .with(CalciteAssert.Config.GEO)
> .query(sql)
> .returns("EXPR$0={\"x\":1,\"y\":2.1}\n");
> }
> {code}
> We will get:
> {code:java}
> org.codehaus.commons.compiler.CompileException: Line 22, Column 124: No
> applicable constructor/method found for actual parameters "int,
> java.math.BigDecimal"; candidates are: "public static
> org.apache.calcite.runtime.GeoFunctions$Geom
> org.apache.calcite.runtime.GeoFunctions.ST_MakePoint(java.math.BigDecimal,
> java.math.BigDecimal, java.math.BigDecimal)", "public static
> org.apache.calcite.runtime.GeoFunctions$Geom
> org.apache.calcite.runtime.GeoFunctions.ST_MakePoint(java.math.BigDecimal,
> java.math.BigDecimal)"
> at org.codehaus.janino.UnitCompiler.compileError(UnitCompiler.java:12211)
> at
> org.codehaus.janino.UnitCompiler.findMostSpecificIInvocable(UnitCompiler.java:9263)
> at org.codehaus.janino.UnitCompiler.findIMethod(UnitCompiler.java:9123)
> at org.codehaus.janino.UnitCompiler.findIMethod(UnitCompiler.java:9025)
> at org.codehaus.janino.UnitCompiler.compileGet2(UnitCompiler.java:5062)
> at org.codehaus.janino.UnitCompiler.access$9100(UnitCompiler.java:215){code}
>
> (3)For some functions, it is too late to fail the query in runtime phase.
> For example: _*RAND_INTEGER*_ adopts _*OperandTypes.or(OperandTypes.NUMERIC,
> OperandTypes.NUMERIC_NUMERIC)*_
> {code:java}
> @Test public void test2() {
> final String sql = "SELECT rand_integer(1.1, 2)";
> CalciteAssert.that()
> .query(sql)
> .planContains("xyxyx")
> .returns("EXPR$0={\"x\":1,\"y\":2.1}\n");
> }{code}
> We will get:
> {code:java}
> org.codehaus.commons.compiler.CompileException: Line 22, Column 100: No
> applicable constructor/method found for actual parameters
> "java.math.BigDecimal, int"; candidates are: "public int
> org.apache.calcite.runtime.RandomFunction.randIntegerSeed(int, int)"
> at org.codehaus.janino.UnitCompiler.compileError(UnitCompiler.java:12211)
> at
> org.codehaus.janino.UnitCompiler.findMostSpecificIInvocable(UnitCompiler.java:9263)
> at org.codehaus.janino.UnitCompiler.findIMethod(UnitCompiler.java:9123){code}
>
> *How to fix?*
> From my personal view, for case (1) and (2), we need to fix it in runtime
> layer with a "try-best" mechanism to convert operand type to match the
> implementation.
> The difference
[jira] [Commented] (CALCITE-3563) Convert function operand type to match implementation if necessary in runtime
[
https://issues.apache.org/jira/browse/CALCITE-3563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16988164#comment-16988164
]
Julian Hyde commented on CALCITE-3563:
--
Enumerable convention implements the {{DECIMAL}} type by working on shifted
integers. Therefore the {{mod}} function should be called with a {{long}}
argument, not a {{java.math.BigDecimal}}.
> Convert function operand type to match implementation if necessary in runtime
> -
>
> Key: CALCITE-3563
> URL: https://issues.apache.org/jira/browse/CALCITE-3563
> Project: Calcite
> Issue Type: Sub-task
> Components: core
>Reporter: Feng Zhu
>Assignee: Feng Zhu
>Priority: Major
>
> Sub-task targets on following issue.
>
> (1)Validation phase allows a wide range of operand types, but the runtime
> implementation does not cover all cases.
> For example, _*SqlFunction(MOD)*_ adopts
> _*OperandTypes.EXACT_NUMERIC_EXACT_NUMERIC*_.
> {code:java}
> @Test public void test0() {
> final String sql = "SELECT mod(12.5, cast(1 as bigint))";
> CalciteAssert.that()
> .query(sql)
> .returns("EXPR$0=0.5\n");
> }{code}
> We will get:
> {code:java}
> java.lang.RuntimeException: while resolving method 'mod[class
> java.math.BigDecimal, long]' in class class
> org.apache.calcite.runtime.SqlFunctions
> at org.apache.calcite.linq4j.tree.Types.lookupMethod(Types.java:323)
> at org.apache.calcite.linq4j.tree.Expressions.call(Expressions.java:445)
> at
> org.apache.calcite.adapter.enumerable.RexImpTable$MethodNameImplementor.implement(RexImpTable.java:2253)
> at
> org.apache.calcite.adapter.enumerable.RexImpTable.implementCall(RexImpTable.java:1195){code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3564) Make operand type check accurate for some functions in validation phase
[ https://issues.apache.org/jira/browse/CALCITE-3564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16988160#comment-16988160 ] Julian Hyde commented on CALCITE-3564: -- I don't understand. Can you please clarify? > Make operand type check accurate for some functions in validation phase > --- > > Key: CALCITE-3564 > URL: https://issues.apache.org/jira/browse/CALCITE-3564 > Project: Calcite > Issue Type: Sub-task >Reporter: Feng Zhu >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3477) Decimal type should not be assigned from other types
[
https://issues.apache.org/jira/browse/CALCITE-3477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16988158#comment-16988158
]
Julian Hyde commented on CALCITE-3477:
--
Please fix the summary of this Jira case. I don't agree that "Decimal type
should not be assigned from other types" and I don't think the SQL standard
agrees with it either.
> Decimal type should not be assigned from other types
>
>
> Key: CALCITE-3477
> URL: https://issues.apache.org/jira/browse/CALCITE-3477
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Kirils Mensikovs
>Assignee: Feng Zhu
>Priority: Major
> Labels: geospatial, pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Geospatial function with integer parameter fails. The expected behavior is to
> cast automatically all number values to BigDecimal.
> {{Example: 'select ST_MAKEPOINT(1.0, 1)'}}
> Return:
> {code:java}
> Error: Error while executing SQL "select ST_MAKEPOINT(1.0, 1)": Error while
> compiling generated Java code:
> public org.apache.calcite.linq4j.Enumerable bind(final
> org.apache.calcite.DataContext root) {
> final org.apache.calcite.linq4j.Enumerable _inputEnumerable =
> org.apache.calcite.linq4j.Linq4j.asEnumerable(new Integer[] {
> 0});
> return new org.apache.calcite.linq4j.AbstractEnumerable(){
> public org.apache.calcite.linq4j.Enumerator enumerator() {
> return new org.apache.calcite.linq4j.Enumerator(){
> public final org.apache.calcite.linq4j.Enumerator inputEnumerator
> = _inputEnumerable.enumerator();
> public void reset() {
> inputEnumerator.reset();
> }
> public boolean moveNext() {
> return inputEnumerator.moveNext();
> }
> public void close() {
> inputEnumerator.close();
> }
> public Object current() {
> final java.math.BigDecimal v =
> $L4J$C$new_java_math_BigDecimal_1_0_;
> return org.apache.calcite.runtime.GeoFunctions.ST_MakePoint(v,
> 1);
> }
> static final java.math.BigDecimal
> $L4J$C$new_java_math_BigDecimal_1_0_ = new java.math.BigDecimal(
> "1.0");
> };
> }
> };
> }
> public Class getElementType() {
> return org.apache.calcite.runtime.GeoFunctions.Geom.class;
> } (state=,code=0)
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3560) Additional calcite.util.Source implementation for generic text source (eg. CharSource)
[
https://issues.apache.org/jira/browse/CALCITE-3560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-3560:
Labels: pull-request-available (was: )
> Additional calcite.util.Source implementation for generic text source (eg.
> CharSource)
> --
>
> Key: CALCITE-3560
> URL: https://issues.apache.org/jira/browse/CALCITE-3560
> Project: Calcite
> Issue Type: Improvement
> Components: csv-adapter, file-adapter
>Affects Versions: 1.21.0
>Reporter: Andrei Sereda
>Assignee: Andrei Sereda
>Priority: Major
> Labels: pull-request-available
>
> Currently calcite {{calcite.util.Source}} interface can be built only from
> [File|https://docs.oracle.com/javase/8/docs/api/java/io/File.html] or
> [URL|https://docs.oracle.com/javase/8/docs/api/java/net/URL.html]. This
> forces data to be stored on disk or accessed remotely using URL api.
> This proposal adds another Source implementation on the top of
> [CharSource|https://guava.dev/releases/19.0/api/docs/com/google/common/io/CharSource.html]
> so calcite adapters can operate on in-memory elements like String or generic
> text sources.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3560) Additional calcite.util.Source implementation for generic text source (eg. CharSource)
[
https://issues.apache.org/jira/browse/CALCITE-3560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Sereda updated CALCITE-3560:
---
Description:
Currently calcite {{calcite.util.Source}} interface can be built only from
[File|https://docs.oracle.com/javase/8/docs/api/java/io/File.html] or
[URL|https://docs.oracle.com/javase/8/docs/api/java/net/URL.html]. This forces
data to be stored on disk or accessed remotely using URL api.
This proposal adds another Source implementation on the top of
[CharSource|https://guava.dev/releases/19.0/api/docs/com/google/common/io/CharSource.html]
so calcite adapters can operate on in-memory elements like String or generic
text sources.
was:
Currently calcite Source interface can be built only from
[File|https://docs.oracle.com/javase/8/docs/api/java/io/File.html] or
[URL|https://docs.oracle.com/javase/8/docs/api/java/net/URL.html]. This forces
data to be stored on disk or accessed remotely using URL api.
This proposal adds another Source implementation on the top of
[CharSource|https://guava.dev/releases/19.0/api/docs/com/google/common/io/CharSource.html]
so calcite adapters can operate on in-memory elements like String or generic
text sources.
> Additional calcite.util.Source implementation for generic text source (eg.
> CharSource)
> --
>
> Key: CALCITE-3560
> URL: https://issues.apache.org/jira/browse/CALCITE-3560
> Project: Calcite
> Issue Type: Improvement
> Components: csv-adapter, file-adapter
>Affects Versions: 1.21.0
>Reporter: Andrei Sereda
>Assignee: Andrei Sereda
>Priority: Major
>
> Currently calcite {{calcite.util.Source}} interface can be built only from
> [File|https://docs.oracle.com/javase/8/docs/api/java/io/File.html] or
> [URL|https://docs.oracle.com/javase/8/docs/api/java/net/URL.html]. This
> forces data to be stored on disk or accessed remotely using URL api.
> This proposal adds another Source implementation on the top of
> [CharSource|https://guava.dev/releases/19.0/api/docs/com/google/common/io/CharSource.html]
> so calcite adapters can operate on in-memory elements like String or generic
> text sources.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3560) Additional calcite.util.Source implementation for generic text source (eg. CharSource)
[ https://issues.apache.org/jira/browse/CALCITE-3560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Sereda updated CALCITE-3560: --- Summary: Additional calcite.util.Source implementation for generic text source (eg. CharSource) (was: Additional Source implementation for generic text source (eg. CharSource)) > Additional calcite.util.Source implementation for generic text source (eg. > CharSource) > -- > > Key: CALCITE-3560 > URL: https://issues.apache.org/jira/browse/CALCITE-3560 > Project: Calcite > Issue Type: Improvement > Components: csv-adapter, file-adapter >Affects Versions: 1.21.0 >Reporter: Andrei Sereda >Assignee: Andrei Sereda >Priority: Major > > Currently calcite Source interface can be built only from > [File|https://docs.oracle.com/javase/8/docs/api/java/io/File.html] or > [URL|https://docs.oracle.com/javase/8/docs/api/java/net/URL.html]. This > forces data to be stored on disk or accessed remotely using URL api. > This proposal adds another Source implementation on the top of > [CharSource|https://guava.dev/releases/19.0/api/docs/com/google/common/io/CharSource.html] > so calcite adapters can operate on in-memory elements like String or generic > text sources. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-3560) Add another Source implementation for generic text source (eg. CharSource)
[ https://issues.apache.org/jira/browse/CALCITE-3560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Sereda updated CALCITE-3560: --- Summary: Add another Source implementation for generic text source (eg. CharSource) (was: Allow generic data source (eg. CharSource) in CSVAdapter and FileAdapter(s)) > Add another Source implementation for generic text source (eg. CharSource) > -- > > Key: CALCITE-3560 > URL: https://issues.apache.org/jira/browse/CALCITE-3560 > Project: Calcite > Issue Type: Improvement > Components: csv-adapter, file-adapter >Affects Versions: 1.21.0 >Reporter: Andrei Sereda >Assignee: Andrei Sereda >Priority: Major > > Currently calcite Source interface can be built only from > [File|https://docs.oracle.com/javase/8/docs/api/java/io/File.html] or > [URL|https://docs.oracle.com/javase/8/docs/api/java/net/URL.html]. This > forces data to be stored on disk or accessed remotely using URL api. > This proposal adds another Source implementation on the top of > [CharSource|https://guava.dev/releases/19.0/api/docs/com/google/common/io/CharSource.html] > so calcite adapters can operate on in-memory elements like String or generic > text sources. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-3560) Additional Source implementation for generic text source (eg. CharSource)
[ https://issues.apache.org/jira/browse/CALCITE-3560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Sereda updated CALCITE-3560: --- Summary: Additional Source implementation for generic text source (eg. CharSource) (was: Add another Source implementation for generic text source (eg. CharSource)) > Additional Source implementation for generic text source (eg. CharSource) > - > > Key: CALCITE-3560 > URL: https://issues.apache.org/jira/browse/CALCITE-3560 > Project: Calcite > Issue Type: Improvement > Components: csv-adapter, file-adapter >Affects Versions: 1.21.0 >Reporter: Andrei Sereda >Assignee: Andrei Sereda >Priority: Major > > Currently calcite Source interface can be built only from > [File|https://docs.oracle.com/javase/8/docs/api/java/io/File.html] or > [URL|https://docs.oracle.com/javase/8/docs/api/java/net/URL.html]. This > forces data to be stored on disk or accessed remotely using URL api. > This proposal adds another Source implementation on the top of > [CharSource|https://guava.dev/releases/19.0/api/docs/com/google/common/io/CharSource.html] > so calcite adapters can operate on in-memory elements like String or generic > text sources. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-3560) Allow generic data source (eg. CharSource) in CSVAdapter and FileAdapter(s)
[ https://issues.apache.org/jira/browse/CALCITE-3560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Sereda updated CALCITE-3560: --- Description: Currently calcite Source interface can be built only from [File|https://docs.oracle.com/javase/8/docs/api/java/io/File.html] or [URL|https://docs.oracle.com/javase/8/docs/api/java/net/URL.html]. This forces data to be stored on disk or accessed remotely using URL api. This proposal adds another Source implementation on the top of [CharSource|https://guava.dev/releases/19.0/api/docs/com/google/common/io/CharSource.html] so calcite adapters can operate on in-memory elements like String or generic text sources. was: Currently CSV Adapter requires data to be stored on disk or remotely because table constructor argument is [URL|https://docs.oracle.com/javase/8/docs/api/java/net/URL.html] or [File|https://docs.oracle.com/javase/8/docs/api/java/io/File.html] Change CSV and File adapter to accept more generic source like [Readable|https://docs.oracle.com/javase/8/docs/api/java/lang/Readable.html] or [InputStream|https://docs.oracle.com/javase/9/docs/api/java/io/InputStream.html] (rather their factory equivalent like [CharSource|https://guava.dev/releases/19.0/api/docs/com/google/common/io/CharSource.html]) so adapters can operate on in-memory elements like String. > Allow generic data source (eg. CharSource) in CSVAdapter and FileAdapter(s) > --- > > Key: CALCITE-3560 > URL: https://issues.apache.org/jira/browse/CALCITE-3560 > Project: Calcite > Issue Type: Improvement > Components: csv-adapter, file-adapter >Affects Versions: 1.21.0 >Reporter: Andrei Sereda >Assignee: Andrei Sereda >Priority: Major > > Currently calcite Source interface can be built only from > [File|https://docs.oracle.com/javase/8/docs/api/java/io/File.html] or > [URL|https://docs.oracle.com/javase/8/docs/api/java/net/URL.html]. This > forces data to be stored on disk or accessed remotely using URL api. > This proposal adds another Source implementation on the top of > [CharSource|https://guava.dev/releases/19.0/api/docs/com/google/common/io/CharSource.html] > so calcite adapters can operate on in-memory elements like String or generic > text sources. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3568) BigQuery SQL dialect doesn't support nested aggregates
[ https://issues.apache.org/jira/browse/CALCITE-3568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16988105#comment-16988105 ] Julian Hyde commented on CALCITE-3568: -- I've removed 'fix version' since there is no PR and no one is working on this. > BigQuery SQL dialect doesn't support nested aggregates > -- > > Key: CALCITE-3568 > URL: https://issues.apache.org/jira/browse/CALCITE-3568 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Divyanshu Srivastava >Priority: Major > > The BigQuerySqlDialect does not support nested aggregates, hence overriding > the supportsNestedAggregations() method in it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-3568) BigQuery SQL dialect doesn't support nested aggregates
[ https://issues.apache.org/jira/browse/CALCITE-3568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde updated CALCITE-3568: - Fix Version/s: (was: 1.22.0) > BigQuery SQL dialect doesn't support nested aggregates > -- > > Key: CALCITE-3568 > URL: https://issues.apache.org/jira/browse/CALCITE-3568 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Divyanshu Srivastava >Priority: Major > > The BigQuerySqlDialect does not support nested aggregates, hence overriding > the supportsNestedAggregations() method in it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-3568) BigQuery SQL dialect doesn't support nested aggregates
[ https://issues.apache.org/jira/browse/CALCITE-3568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde updated CALCITE-3568: - Summary: BigQuery SQL dialect doesn't support nested aggregates (was: BigQuery SQL dialect doesn't support nested aggregates.) > BigQuery SQL dialect doesn't support nested aggregates > -- > > Key: CALCITE-3568 > URL: https://issues.apache.org/jira/browse/CALCITE-3568 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Divyanshu Srivastava >Priority: Major > Fix For: 1.22.0 > > > The BigQuerySqlDialect does not support nested aggregates, hence overriding > the supportsNestedAggregations() method in it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-3381) When generating SQL for BigQuery (via unparsing), convert Calcite SQL types to BigQuery types
[ https://issues.apache.org/jira/browse/CALCITE-3381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rui Wang updated CALCITE-3381: -- Issue Type: Improvement (was: New Feature) > When generating SQL for BigQuery (via unparsing), convert Calcite SQL types > to BigQuery types > - > > Key: CALCITE-3381 > URL: https://issues.apache.org/jira/browse/CALCITE-3381 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.21.0 >Reporter: Kirill Kozlov >Assignee: Rui Wang >Priority: Minor > Labels: pull-request-available > Fix For: 1.22.0 > > Time Spent: 5.5h > Remaining Estimate: 0h > > When using `SqlImplementor.SimpleContext#toSql` with BigQuerySqlDialect on > Rel nodes containing `CAST` need to convert Calcite SqlTypeName to BigQuery > supported types > ([https://cloud.google.com/bigquery/docs/reference/standard-sql/data-types]). > I believe this can be accomplished by Overriding > BigQuerySqlDialect#getCastSpec method. > Example: VARCHAR should become a STRING, BOOLEAN - BOOL, and so on. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3568) BigQuery SQL dialect doesn't support nested aggregates.
[ https://issues.apache.org/jira/browse/CALCITE-3568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16988102#comment-16988102 ] Rui Wang commented on CALCITE-3568: --- [~divyanshu.s95] good catch! Do you plan to work on this Jira to make it released into 1.22.0? If so it would be better to assign this Jira to yourself as 1.22.0 releasing will happen soon. > BigQuery SQL dialect doesn't support nested aggregates. > --- > > Key: CALCITE-3568 > URL: https://issues.apache.org/jira/browse/CALCITE-3568 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Divyanshu Srivastava >Priority: Major > Fix For: 1.22.0 > > > The BigQuerySqlDialect does not support nested aggregates, hence overriding > the supportsNestedAggregations() method in it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-3560) Allow generic data source (eg. CharSource) in CSVAdapter and FileAdapter(s)
[ https://issues.apache.org/jira/browse/CALCITE-3560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Sereda updated CALCITE-3560: --- Description: Currently CSV Adapter requires data to be stored on disk or remotely because table constructor argument is [URL|https://docs.oracle.com/javase/8/docs/api/java/net/URL.html] or [File|https://docs.oracle.com/javase/8/docs/api/java/io/File.html] Change CSV and File adapter to accept more generic source like [Readable|https://docs.oracle.com/javase/8/docs/api/java/lang/Readable.html] or [InputStream|https://docs.oracle.com/javase/9/docs/api/java/io/InputStream.html] (rather their factory equivalent like [CharSource|https://guava.dev/releases/19.0/api/docs/com/google/common/io/CharSource.html]) so adapters can operate on in-memory elements like String. was: Currently CSV Adapter requires data to be stored on disk or remotely because table constructor argument is [URL|https://docs.oracle.com/javase/8/docs/api/java/net/URL.html]. Change CSV and File adapter to accept more generic source like [Readable|https://docs.oracle.com/javase/8/docs/api/java/lang/Readable.html] or [InputStream|https://docs.oracle.com/javase/9/docs/api/java/io/InputStream.html] (rather their factory equivalent like [ByteSource|https://guava.dev/releases/19.0/api/docs/com/google/common/io/ByteSource.html]) so adapters can operate on in-memory elements like String. > Allow generic data source (eg. CharSource) in CSVAdapter and FileAdapter(s) > --- > > Key: CALCITE-3560 > URL: https://issues.apache.org/jira/browse/CALCITE-3560 > Project: Calcite > Issue Type: Improvement > Components: csv-adapter, file-adapter >Affects Versions: 1.21.0 >Reporter: Andrei Sereda >Assignee: Andrei Sereda >Priority: Major > > Currently CSV Adapter requires data to be stored on disk or remotely because > table constructor argument is > [URL|https://docs.oracle.com/javase/8/docs/api/java/net/URL.html] or > [File|https://docs.oracle.com/javase/8/docs/api/java/io/File.html] > Change CSV and File adapter to accept more generic source like > [Readable|https://docs.oracle.com/javase/8/docs/api/java/lang/Readable.html] > or > [InputStream|https://docs.oracle.com/javase/9/docs/api/java/io/InputStream.html] > (rather their factory equivalent like > [CharSource|https://guava.dev/releases/19.0/api/docs/com/google/common/io/CharSource.html]) > so adapters can operate on in-memory elements like String. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-3560) Allow generic data source (eg. CharSource) in CSVAdapter or FileAdapter(s)
[ https://issues.apache.org/jira/browse/CALCITE-3560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Sereda updated CALCITE-3560: --- Summary: Allow generic data source (eg. CharSource) in CSVAdapter or FileAdapter(s) (was: Allow generic data source (eg. ByteSource) in CSVAdapter or FileAdapter(s)) > Allow generic data source (eg. CharSource) in CSVAdapter or FileAdapter(s) > -- > > Key: CALCITE-3560 > URL: https://issues.apache.org/jira/browse/CALCITE-3560 > Project: Calcite > Issue Type: Improvement > Components: csv-adapter, file-adapter >Affects Versions: 1.21.0 >Reporter: Andrei Sereda >Assignee: Andrei Sereda >Priority: Major > > Currently CSV Adapter requires data to be stored on disk or remotely because > table constructor argument is > [URL|https://docs.oracle.com/javase/8/docs/api/java/net/URL.html]. > Change CSV and File adapter to accept more generic source like > [Readable|https://docs.oracle.com/javase/8/docs/api/java/lang/Readable.html] > or > [InputStream|https://docs.oracle.com/javase/9/docs/api/java/io/InputStream.html] > (rather their factory equivalent like > [ByteSource|https://guava.dev/releases/19.0/api/docs/com/google/common/io/ByteSource.html]) > so adapters can operate on in-memory elements like String. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-3560) Allow generic data source (eg. CharSource) in CSVAdapter and FileAdapter(s)
[ https://issues.apache.org/jira/browse/CALCITE-3560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Sereda updated CALCITE-3560: --- Summary: Allow generic data source (eg. CharSource) in CSVAdapter and FileAdapter(s) (was: Allow generic data source (eg. CharSource) in CSVAdapter or FileAdapter(s)) > Allow generic data source (eg. CharSource) in CSVAdapter and FileAdapter(s) > --- > > Key: CALCITE-3560 > URL: https://issues.apache.org/jira/browse/CALCITE-3560 > Project: Calcite > Issue Type: Improvement > Components: csv-adapter, file-adapter >Affects Versions: 1.21.0 >Reporter: Andrei Sereda >Assignee: Andrei Sereda >Priority: Major > > Currently CSV Adapter requires data to be stored on disk or remotely because > table constructor argument is > [URL|https://docs.oracle.com/javase/8/docs/api/java/net/URL.html]. > Change CSV and File adapter to accept more generic source like > [Readable|https://docs.oracle.com/javase/8/docs/api/java/lang/Readable.html] > or > [InputStream|https://docs.oracle.com/javase/9/docs/api/java/io/InputStream.html] > (rather their factory equivalent like > [ByteSource|https://guava.dev/releases/19.0/api/docs/com/google/common/io/ByteSource.html]) > so adapters can operate on in-memory elements like String. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-3569) IndexOutOfBoundsException when pushing simplifed filter to view
[
https://issues.apache.org/jira/browse/CALCITE-3569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-3569:
Labels: pull-request-available (was: )
> IndexOutOfBoundsException when pushing simplifed filter to view
> ---
>
> Key: CALCITE-3569
> URL: https://issues.apache.org/jira/browse/CALCITE-3569
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.21.0
>Reporter: Chunwei Lei
>Assignee: Chunwei Lei
>Priority: Major
> Labels: pull-request-available
>
> It can be reproduced by the following test.
> {code:java}
> // MaterializationTest.java
> @Test public void testAggregate7() {
> try (TryThreadLocal.Memo ignored = Prepare.THREAD_TRIM.push(true)) {
> MaterializationService.setThreadLocal();
> CalciteAssert.that()
> .withMaterializations(
> HR_FKUK_MODEL,
> "m0",
> "select 11 as \"empno\", 22 as \"sal\", count(*) from \"emps\"
> group by 11, 22")
> .query(
> "select * from\n"
> + "(select 11 as \"empno\", 22 as \"sal\", count(*)\n"
> + "from \"emps\" group by 11, 22) tmp\n"
> + "where \"sal\" = 33")
> .enableMaterializations(true)
> .explainContains("EnumerableValues(tuples=[[]])");
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3569) IndexOutOfBoundsException when pushing simplifed filter to view
[
https://issues.apache.org/jira/browse/CALCITE-3569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chunwei Lei updated CALCITE-3569:
-
Summary: IndexOutOfBoundsException when pushing simplifed filter to view
(was: IndexOutOfBoundsException when pushing FALSE filter to view)
> IndexOutOfBoundsException when pushing simplifed filter to view
> ---
>
> Key: CALCITE-3569
> URL: https://issues.apache.org/jira/browse/CALCITE-3569
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.21.0
>Reporter: Chunwei Lei
>Assignee: Chunwei Lei
>Priority: Major
>
> It can be reproduced by the following test.
> {code:java}
> // MaterializationTest.java
> @Test public void testAggregate7() {
> try (TryThreadLocal.Memo ignored = Prepare.THREAD_TRIM.push(true)) {
> MaterializationService.setThreadLocal();
> CalciteAssert.that()
> .withMaterializations(
> HR_FKUK_MODEL,
> "m0",
> "select 11 as \"empno\", 22 as \"sal\", count(*) from \"emps\"
> group by 11, 22")
> .query(
> "select * from\n"
> + "(select 11 as \"empno\", 22 as \"sal\", count(*)\n"
> + "from \"emps\" group by 11, 22) tmp\n"
> + "where \"sal\" = 33")
> .enableMaterializations(true)
> .explainContains("EnumerableValues(tuples=[[]])");
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-3569) IndexOutOfBoundsException when pushing FALSE filter to view
Chunwei Lei created CALCITE-3569:
Summary: IndexOutOfBoundsException when pushing FALSE filter to
view
Key: CALCITE-3569
URL: https://issues.apache.org/jira/browse/CALCITE-3569
Project: Calcite
Issue Type: Improvement
Components: core
Affects Versions: 1.21.0
Reporter: Chunwei Lei
Assignee: Chunwei Lei
It can be reproduced by the following test.
{code:java}
// MaterializationTest.java
@Test public void testAggregate7() {
try (TryThreadLocal.Memo ignored = Prepare.THREAD_TRIM.push(true)) {
MaterializationService.setThreadLocal();
CalciteAssert.that()
.withMaterializations(
HR_FKUK_MODEL,
"m0",
"select 11 as \"empno\", 22 as \"sal\", count(*) from \"emps\"
group by 11, 22")
.query(
"select * from\n"
+ "(select 11 as \"empno\", 22 as \"sal\", count(*)\n"
+ "from \"emps\" group by 11, 22) tmp\n"
+ "where \"sal\" = 33")
.enableMaterializations(true)
.explainContains("EnumerableValues(tuples=[[]])");
}
}
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3556) Add TO_NUMBER function
[
https://issues.apache.org/jira/browse/CALCITE-3556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
vaibhav jain updated CALCITE-3556:
--
Description:
TO_NUMBER error:
No match found for function signature TO_NUMBER(, )
Example :
SELECT TO_NUMBER ('1234', '')
was:
Handling of TO_NUMBER method.
> Add TO_NUMBER function
> --
>
> Key: CALCITE-3556
> URL: https://issues.apache.org/jira/browse/CALCITE-3556
> Project: Calcite
> Issue Type: New Feature
>Reporter: vaibhav jain
>Priority: Major
> Labels: pull-request-available
> Time Spent: 40m
> Remaining Estimate: 0h
>
> TO_NUMBER error:
> No match found for function signature TO_NUMBER(, )
> Example :
> SELECT TO_NUMBER ('1234', '')
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3567) UNNEST(RECORDTYPE(MAP)) not supported
[
https://issues.apache.org/jira/browse/CALCITE-3567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-3567:
Labels: pull-request-available (was: )
> UNNEST(RECORDTYPE(MAP)) not supported
> -
>
> Key: CALCITE-3567
> URL: https://issues.apache.org/jira/browse/CALCITE-3567
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Major
> Labels: pull-request-available
>
> UNNEST(RECORDTYPE(ARRAY)) and UNNEST(RECORDTYPE(MULTISET)) works well, but
> UNNEST(RECORDTYPE(MAP)) is not supported.
> {code:java}
> // JdbcTest
> @Test public void testUnnestRecordType() {
> // unnest(RecordType(Array))
> CalciteAssert.that()
> .query("select * from unnest\n"
> + "(select t.x from (values array[10, 20], array[30, 40]) as
> t(x))\n"
> + " with ordinality as t(a, o)")
> .returnsUnordered("A=10; O=1", "A=20; O=2",
> "A=30; O=1", "A=40; O=2");
> // unnest(RecordType(Multiset))
> CalciteAssert.that()
> .query("select * from unnest\n"
> + "(select t.x from (values multiset[10, 20], array[30, 40]) as
> t(x))\n"
> + " with ordinality as t(a, o)")
> .returnsUnordered("A=10; O=1", "A=20; O=2",
> "A=30; O=1", "A=40; O=2");
> // unnest(RecordType(Map))
> CalciteAssert.that()
> .query("select * from unnest\n"
> + "(select t.x from (values map['a', 20, 'b', 30], map['c', 40])
> as t(x))\n"
> + " with ordinality as t(a, b, o)")
> .returnsUnordered("A=a; B=20; O=1", "A=B; B=30; O=2",
> "A=c; B=40; O=1");
> }
> {code}
> In the case, test for *unnest(RecordType(Array))* and
> *unnest(RecordType(Multiset))* success, but got exception for
> *unnest(RecordType(Map))*.
> For the first two test of *unnest(RecordType(Array))* and
> *unnest(RecordType(Multiset))*, the relnode tree with type is like this
> {noformat}
> EnumerableUncollect(withOrdinality=[true]), type = RecordType(INTEGER EXPR$0,
> INTEGER ORDINALITY)
> EnumerableUnion(all=[true]), type = RecordType(INTEGER ARRAY EXPR$0)
> EnumerableCalc(expr#0=[{inputs}], expr#1=[10], expr#2=[20],
> expr#3=[ARRAY($t1, $t2)], EXPR$0=[$t3]), type = RecordType(INTEGER ARRAY
> EXPR$0)
> EnumerableValues(tuples=[[{ 0 }]]), type = RecordType(INTEGER ZERO)
> EnumerableCalc(expr#0=[{inputs}], expr#1=[30], expr#2=[40],
> expr#3=[ARRAY($t1, $t2)], EXPR$0=[$t3]), type = RecordType(INTEGER ARRAY
> EXPR$0)
> EnumerableValues(tuples=[[{ 0 }]]), type = RecordType(INTEGER ZERO)
> EnumerableUncollect(withOrdinality=[true]), type = RecordType(INTEGER EXPR$0,
> INTEGER ORDINALITY)
> EnumerableUnion(all=[true]), type = RecordType(INTEGER ARRAY EXPR$0)
> EnumerableCalc(expr#0=[{inputs}], expr#1=[$SLICE($t0)], EXPR$0=[$t1]),
> type = RecordType(INTEGER MULTISET EXPR$0)
> EnumerableCollect(field=[EXPR$0]), type = RecordType(RecordType(INTEGER
> ROW_VALUE) MULTISET EXPR$0)
> EnumerableValues(tuples=[[{ 10 }, { 20 }]]), type =
> RecordType(INTEGER ROW_VALUE)
> EnumerableCalc(expr#0=[{inputs}], expr#1=[30], expr#2=[40],
> expr#3=[ARRAY($t1, $t2)], EXPR$0=[$t3]), type = RecordType(INTEGER ARRAY
> EXPR$0)
> EnumerableValues(tuples=[[{ 0 }]]), type = RecordType(INTEGER ZERO)
> {noformat}
> Part of the stacktrace of the exception is:
> {code:java}
> Cannot apply 'UNNEST' to arguments of type 'UNNEST( INTEGER) MAP X)>)'. Supported form(s): 'UNNEST()'
> 'UNNEST()'
> 'UNNEST()'
> UNNEST()
> 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:463)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:839)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:824)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:4905)
> at
> org.apache.calcite.sql.SqlCallBinding.newValidationSignatureError(SqlCallBinding.java:280)
> at
> org.apache.calcite.sql.type.CompositeOperandTypeChecker.checkOperandTypes(CompositeOperandTypeChecker.java:261)
> at
> org.apache.calcite.sql.SqlOperator.checkOperandTypes(SqlOperator.java:668)
> at
> org.apache.calcite.sql.SqlOperator.validateOperands(SqlOperator.java:432)
> at
>
[jira] [Created] (CALCITE-3568) BigQuery SQL dialect doesn't support nested aggregates.
Divyanshu Srivastava created CALCITE-3568: - Summary: BigQuery SQL dialect doesn't support nested aggregates. Key: CALCITE-3568 URL: https://issues.apache.org/jira/browse/CALCITE-3568 Project: Calcite Issue Type: Improvement Components: core Reporter: Divyanshu Srivastava Fix For: 1.22.0 The BigQuerySqlDialect does not support nested aggregates, hence overriding the supportsNestedAggregations() method in it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-3548) ./gradlew :ubenchmark:jmh cannot find benchmark to run
[ https://issues.apache.org/jira/browse/CALCITE-3548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Sitnikov updated CALCITE-3548: --- Fix Version/s: 1.22.0 > ./gradlew :ubenchmark:jmh cannot find benchmark to run > -- > > Key: CALCITE-3548 > URL: https://issues.apache.org/jira/browse/CALCITE-3548 > Project: Calcite > Issue Type: Bug > Components: build >Reporter: Rui Wang >Assignee: Rui Wang >Priority: Major > Labels: pull-request-available > Fix For: 1.22.0 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > Per https://github.com/melix/jmh-gradle-plugin#configuration, > jmh-gradle-plugin expects a file structure as: src/jmh/java, but current > structure is src/main/jmh, thus ./gradlew :ubenchmark:jmh reports no > benchmark to run. > Change the structure accordingly fixed this problem. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CALCITE-3548) ./gradlew :ubenchmark:jmh cannot find benchmark to run
[ https://issues.apache.org/jira/browse/CALCITE-3548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Sitnikov resolved CALCITE-3548. Resolution: Fixed Fixed in [https://github.com/apache/calcite/commit/ecc68aca85f756bb2b29b56dba4322c342f5d693] Thanks, Rui > ./gradlew :ubenchmark:jmh cannot find benchmark to run > -- > > Key: CALCITE-3548 > URL: https://issues.apache.org/jira/browse/CALCITE-3548 > Project: Calcite > Issue Type: Bug > Components: build >Reporter: Rui Wang >Assignee: Rui Wang >Priority: Major > Labels: pull-request-available > Fix For: 1.22.0 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > Per https://github.com/melix/jmh-gradle-plugin#configuration, > jmh-gradle-plugin expects a file structure as: src/jmh/java, but current > structure is src/main/jmh, thus ./gradlew :ubenchmark:jmh reports no > benchmark to run. > Change the structure accordingly fixed this problem. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-3124) Infinite rule matching when AggregateRemoveRule is enabled for SUM0
[
https://issues.apache.org/jira/browse/CALCITE-3124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16979110#comment-16979110
]
Jin Xing edited comment on CALCITE-3124 at 12/4/19 11:44 AM:
-
Sql in testHavingNot2 and its corresponding plan are as below:
{code:java}
LogicalProject(EXPR$0=[1])
LogicalFilter(condition=[>=($1, 2)]) --> Filter0
LogicalAggregate(group=[{0}], agg#0=[SUM($1)]) -->
Aggregate0
LogicalProject(store_street_address=[$5], grocery_sqft=[$16])
EnumerableTableScan(table=[[foodmart2, store]])
{code}
The infinite loop happens by below steps:
Step-1
Aggregate0 can be transformed to below equivalent plans and collect into
RelSubset-A
{code:java}
RelSubset-A:
1. Aggregate0
LogicalAggregate(group=[{0}], agg#0=[SUM($1)])
LogicalProject(store_street_address=[$5], grocery_sqft=[$16])
EnumerableTableScan(table=[[foodmart2, store]])
2. Aggregate0-equiv0 (transformed by AggregateReduceFunctionsRule,
AggregateRemoveRule, ProjectMergeRule)
LogicalProject(store_street_address=[$5], $f1=[CASE(=(CASE(IS NOT NULL($16),
1:BIGINT, 0:BIGINT), 0), null:INTEGER, COALESCE($16, 0))])
EnumerableTableScan(subset=[rel#62:Subset#0.NONE.[]], table=[[foodmart2,
store]])
3. Aggregate0-equiv1 (transformed by AggregateProjectMergeRule,
AggregateRemoveRule)
LogicalProject(store_street_address=[$5], grocery_sqft=[$16])
EnumerableTableScan(table=[[foodmart2, store]])
{code}
Step-2
RelSubset-A is child node of Filter0 and FilterProjectTransposeRule will
transform Filter0 with Aggregate0-equiv0 as below:
{code:java}
From:
LogicalFilter(condition=[>=($1, 2)])
LogicalProject(store_street_address=[$5], $f1=[CASE(=(CASE(IS NOT NULL($16),
1:BIGINT, 0:BIGINT), 0), null:INTEGER, COALESCE($16, 0))])
EnumerableTableScan(table=[[foodmart2, store]])
To:
LogicalProject(store_street_address=[$5], $f1=[CASE(=(CASE(IS NOT NULL($16),
1:BIGINT, 0:BIGINT), 0), null:INTEGER, COALESCE($16, 0))])
-->Filter0-equiv
LogicalFilter(condition=[>=($CASE(=(CASE(IS NOT NULL($16), 1:BIGINT,
0:BIGINT), 0), null:INTEGER, COALESCE($16, 0)), 2)])
EnumerableTableScan(table=[[foodmart2, store]]){code}
Step-3
ProjectFilterTransposeRule will transform Filter0-equiv as below:
{code:java}
From:
LogicalProject(store_street_address=[$5], $f1=[CASE(=(CASE(IS NOT NULL($16),
1:BIGINT, 0:BIGINT), 0), null:INTEGER, COALESCE($16, 0))])
-->Filter0-equiv
LogicalFilter(condition=[>=($CASE(=(CASE(IS NOT NULL($16), 1:BIGINT,
0:BIGINT), 0), null:INTEGER, COALESCE($16, 0)), 2)])
EnumerableTableScan(table=[[foodmart2, store]])
To:
LogicalProject(store_street_address=[$0], $f1=[CASE(=(CASE(IS NOT NULL($1),
1:BIGINT, 0:BIGINT), 0), null:INTEGER, COALESCE($1, 0))])
LogicalFilter(condition=[>=($CASE(=(CASE(IS NOT NULL($1), 1:BIGINT,
0:BIGINT), 0), null:INTEGER, COALESCE($1, 0)), 2)])
-> FilterX
LogicalProject([$5], [$16]) ---> ProjectX
EnumerableTableScan(table=[[foodmart2, store]]){code}
We will find ProjectX exactly exists in RelSubset-A as Aggregate0-equiv1, thus
FilterProjectTransposeRule will transform FilterX with Aggregate0-equiv0 as
below:
{code:java}
From:
LogicalFilter(condition=[>=($CASE(=(CASE(IS NOT NULL($1), 1:BIGINT, 0:BIGINT),
0), null:INTEGER, COALESCE($1, 0)), 2)])
LogicalProject(store_street_address=[$5], $f1=[CASE(=(CASE(IS NOT NULL($16),
1:BIGINT, 0:BIGINT), 0), null:INTEGER, COALESCE($16, 0))])
EnumerableTableScan(subset=[rel#62:Subset#0.NONE.[]], table=[[foodmart2,
store]])
To:
LogicalProject(store_street_address=[$5], $f1=[CASE(=(CASE(IS NOT NULL($16),
1:BIGINT, 0:BIGINT), 0), null:INTEGER, COALESCE($16, 0))])
LogicalFilter(condition=[>=($CASE(=(CASE(IS NOT NULL(CASE(=(CASE(IS NOT
NULL($16), 1:BIGINT, 0:BIGINT), 0), null:INTEGER, COALESCE($16, 0))), 1:BIGINT,
0:BIGINT), 0), null:INTEGER, COALESCE($1, 0)), 2)])
EnumerableTableScan(subset=[rel#62:Subset#0.NONE.[]], table=[[foodmart2,
store]]){code}
As we can see, a more complex LogicalFilter is generated and then step-3 will
happen again. And then step-2 & step-3 will alternate infinitely.
was (Author: jinxing6...@126.com):
Sql in testHavingNot2 and its corresponding plan are as below:
{code:java}
LogicalProject(EXPR$0=[1])
LogicalFilter(condition=[>=($1, 2)])
> Filter0
LogicalAggregate(group=[{0}], agg#0=[SUM($1)])
> Aggregate0
LogicalProject(store_street_address=[$5], grocery_sqft=[$16])
EnumerableTableScan(table=[[foodmart2, store]])
{code}
The infinite loop happens by below steps:
Step-1
Aggregate0 can be transformed to below equivalent plans and collect into
[jira] [Commented] (CALCITE-3550) Make SqlTypeAssignmentRules conversion mapping pluggable
[ https://issues.apache.org/jira/browse/CALCITE-3550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16987755#comment-16987755 ] Danny Chen commented on CALCITE-3550: - In order to avoid pass the custom rules around, i made a thread local variable in SqlTypeCoercionRules, we use this variable to set up the custom rules, then we can still make out tool method like "SqlTypeUtil.canCastFrom" the same as before. > Make SqlTypeAssignmentRules conversion mapping pluggable > > > Key: CALCITE-3550 > URL: https://issues.apache.org/jira/browse/CALCITE-3550 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.21.0 >Reporter: Danny Chen >Priority: Major > Labels: pull-request-available > Fix For: 1.22.0 > > Time Spent: 10m > Remaining Estimate: 0h > > In CALCITE-2302, we introduce implicit type coercion for Calcite builtin > conversion behaviors, we also expand the conversion matrix to support more > type conversion compared to the old matrix [1], that means, we implement a > conversion matrix of our Calcite style. > As a library of other sql engines, i think we should make the conversion > matrix pluggable, so that each engine can customize if the conversion is > valid from a type to another. > We have made the TypeCoercion pluggable/customizable, so if this matrix is > also pluggable, then, the whole conversion behavior can be customized. > That would give the type conversion of Calcite a pretty good flexibility. > [1] > https://docs.google.com/spreadsheets/d/1GhleX5h5W8-kJKh7NMJ4vtoE78pwfaZRJl88ULX_MgU/edit?usp=sharing -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-3550) Make SqlTypeAssignmentRules conversion mapping pluggable
[ https://issues.apache.org/jira/browse/CALCITE-3550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-3550: Labels: pull-request-available (was: ) > Make SqlTypeAssignmentRules conversion mapping pluggable > > > Key: CALCITE-3550 > URL: https://issues.apache.org/jira/browse/CALCITE-3550 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.21.0 >Reporter: Danny Chen >Priority: Major > Labels: pull-request-available > Fix For: 1.22.0 > > > In CALCITE-2302, we introduce implicit type coercion for Calcite builtin > conversion behaviors, we also expand the conversion matrix to support more > type conversion compared to the old matrix [1], that means, we implement a > conversion matrix of our Calcite style. > As a library of other sql engines, i think we should make the conversion > matrix pluggable, so that each engine can customize if the conversion is > valid from a type to another. > We have made the TypeCoercion pluggable/customizable, so if this matrix is > also pluggable, then, the whole conversion behavior can be customized. > That would give the type conversion of Calcite a pretty good flexibility. > [1] > https://docs.google.com/spreadsheets/d/1GhleX5h5W8-kJKh7NMJ4vtoE78pwfaZRJl88ULX_MgU/edit?usp=sharing -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-3565) Explicitly cast assignable operand types to decimal for udf
[
https://issues.apache.org/jira/browse/CALCITE-3565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Feng Zhu updated CALCITE-3565:
--
Component/s: core
> Explicitly cast assignable operand types to decimal for udf
> ---
>
> Key: CALCITE-3565
> URL: https://issues.apache.org/jira/browse/CALCITE-3565
> Project: Calcite
> Issue Type: Sub-task
> Components: core
>Reporter: Feng Zhu
>Assignee: Feng Zhu
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Type is assignable conceptually, but in the runtime phase, explicite cast is
> still required.
> For example, according to _*SqlTypeAssignmentRules*_,
> *_ST_MakePoint(Decimal, Decimal)_* also accepts operands with (_Integer_,
> _Decimal_) types, because Decimal is assignable from Integer.
> {code:java}
> @Test public void test1() {
> final String sql = "SELECT ST_MakePoint(1, 2.1)";
> CalciteAssert.that()
> .with(CalciteAssert.Config.GEO)
> .query(sql)
> .returns("EXPR$0={\"x\":1,\"y\":2.1}\n");
> }
> {code}
> We will get:
> {code:java}
> org.codehaus.commons.compiler.CompileException: Line 22, Column 124: No
> applicable constructor/method found for actual parameters "int,
> java.math.BigDecimal"; candidates are: "public static
> org.apache.calcite.runtime.GeoFunctions$Geom
> org.apache.calcite.runtime.GeoFunctions.ST_MakePoint(java.math.BigDecimal,
> java.math.BigDecimal, java.math.BigDecimal)", "public static
> org.apache.calcite.runtime.GeoFunctions$Geom
> org.apache.calcite.runtime.GeoFunctions.ST_MakePoint(java.math.BigDecimal,
> java.math.BigDecimal)"
> at org.codehaus.janino.UnitCompiler.compileError(UnitCompiler.java:12211)
> at
> org.codehaus.janino.UnitCompiler.findMostSpecificIInvocable(UnitCompiler.java:9263)
> at org.codehaus.janino.UnitCompiler.findIMethod(UnitCompiler.java:9123)
> at org.codehaus.janino.UnitCompiler.findIMethod(UnitCompiler.java:9025)
> at org.codehaus.janino.UnitCompiler.compileGet2(UnitCompiler.java:5062)
> at org.codehaus.janino.UnitCompiler.access$9100(UnitCompiler.java:215){code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3565) Explicitly cast assignable operand types to decimal for udf
[
https://issues.apache.org/jira/browse/CALCITE-3565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-3565:
Labels: pull-request-available (was: )
> Explicitly cast assignable operand types to decimal for udf
> ---
>
> Key: CALCITE-3565
> URL: https://issues.apache.org/jira/browse/CALCITE-3565
> Project: Calcite
> Issue Type: Sub-task
>Reporter: Feng Zhu
>Assignee: Feng Zhu
>Priority: Major
> Labels: pull-request-available
>
> Type is assignable conceptually, but in the runtime phase, explicite cast is
> still required.
> For example, according to _*SqlTypeAssignmentRules*_,
> *_ST_MakePoint(Decimal, Decimal)_* also accepts operands with (_Integer_,
> _Decimal_) types, because Decimal is assignable from Integer.
> {code:java}
> @Test public void test1() {
> final String sql = "SELECT ST_MakePoint(1, 2.1)";
> CalciteAssert.that()
> .with(CalciteAssert.Config.GEO)
> .query(sql)
> .returns("EXPR$0={\"x\":1,\"y\":2.1}\n");
> }
> {code}
> We will get:
> {code:java}
> org.codehaus.commons.compiler.CompileException: Line 22, Column 124: No
> applicable constructor/method found for actual parameters "int,
> java.math.BigDecimal"; candidates are: "public static
> org.apache.calcite.runtime.GeoFunctions$Geom
> org.apache.calcite.runtime.GeoFunctions.ST_MakePoint(java.math.BigDecimal,
> java.math.BigDecimal, java.math.BigDecimal)", "public static
> org.apache.calcite.runtime.GeoFunctions$Geom
> org.apache.calcite.runtime.GeoFunctions.ST_MakePoint(java.math.BigDecimal,
> java.math.BigDecimal)"
> at org.codehaus.janino.UnitCompiler.compileError(UnitCompiler.java:12211)
> at
> org.codehaus.janino.UnitCompiler.findMostSpecificIInvocable(UnitCompiler.java:9263)
> at org.codehaus.janino.UnitCompiler.findIMethod(UnitCompiler.java:9123)
> at org.codehaus.janino.UnitCompiler.findIMethod(UnitCompiler.java:9025)
> at org.codehaus.janino.UnitCompiler.compileGet2(UnitCompiler.java:5062)
> at org.codehaus.janino.UnitCompiler.access$9100(UnitCompiler.java:215){code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3556) Add TO_NUMBER function
[ https://issues.apache.org/jira/browse/CALCITE-3556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16987727#comment-16987727 ] vaibhav jain commented on CALCITE-3556: --- I have the solution and made the changes for the same in the code, just few refactoring needs to be made. I will raise the pull request in 1-2 days. > Add TO_NUMBER function > -- > > Key: CALCITE-3556 > URL: https://issues.apache.org/jira/browse/CALCITE-3556 > Project: Calcite > Issue Type: New Feature >Reporter: vaibhav jain >Priority: Major > Labels: pull-request-available > Time Spent: 40m > Remaining Estimate: 0h > > Handling of TO_NUMBER method. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-3556) Add TO_NUMBER function
[ https://issues.apache.org/jira/browse/CALCITE-3556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] vaibhav jain updated CALCITE-3556: -- Description: Handling of TO_NUMBER method. was: Handling of TO_NUMBER method. Code is ready will create pull request. > Add TO_NUMBER function > -- > > Key: CALCITE-3556 > URL: https://issues.apache.org/jira/browse/CALCITE-3556 > Project: Calcite > Issue Type: New Feature >Reporter: vaibhav jain >Priority: Major > Labels: pull-request-available > Time Spent: 40m > Remaining Estimate: 0h > > Handling of TO_NUMBER method. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-3567) UNNEST(RECORDTYPE(MAP)) not supported
Wang Yanlin created CALCITE-3567:
Summary: UNNEST(RECORDTYPE(MAP)) not supported
Key: CALCITE-3567
URL: https://issues.apache.org/jira/browse/CALCITE-3567
Project: Calcite
Issue Type: Bug
Reporter: Wang Yanlin
UNNEST(RECORDTYPE(ARRAY)) and UNNEST(RECORDTYPE(MULTISET)) works well, but
UNNEST(RECORDTYPE(MAP)) is not supported.
{code:java}
// JdbcTest
@Test public void testUnnestRecordType() {
// unnest(RecordType(Array))
CalciteAssert.that()
.query("select * from unnest\n"
+ "(select t.x from (values array[10, 20], array[30, 40]) as
t(x))\n"
+ " with ordinality as t(a, o)")
.returnsUnordered("A=10; O=1", "A=20; O=2",
"A=30; O=1", "A=40; O=2");
// unnest(RecordType(Multiset))
CalciteAssert.that()
.query("select * from unnest\n"
+ "(select t.x from (values multiset[10, 20], array[30, 40]) as
t(x))\n"
+ " with ordinality as t(a, o)")
.returnsUnordered("A=10; O=1", "A=20; O=2",
"A=30; O=1", "A=40; O=2");
// unnest(RecordType(Map))
CalciteAssert.that()
.query("select * from unnest\n"
+ "(select t.x from (values map['a', 20, 'b', 30], map['c', 40]) as
t(x))\n"
+ " with ordinality as t(a, b, o)")
.returnsUnordered("A=a; B=20; O=1", "A=B; B=30; O=2",
"A=c; B=40; O=1");
}
{code}
In the case, test for *unnest(RecordType(Array))* and
*unnest(RecordType(Multiset))* success, but got exception for
*unnest(RecordType(Map))*.
For the first two test of *unnest(RecordType(Array))* and
*unnest(RecordType(Multiset))*, the relnode tree with type is like this
{noformat}
EnumerableUncollect(withOrdinality=[true]), type = RecordType(INTEGER EXPR$0,
INTEGER ORDINALITY)
EnumerableUnion(all=[true]), type = RecordType(INTEGER ARRAY EXPR$0)
EnumerableCalc(expr#0=[{inputs}], expr#1=[10], expr#2=[20],
expr#3=[ARRAY($t1, $t2)], EXPR$0=[$t3]), type = RecordType(INTEGER ARRAY EXPR$0)
EnumerableValues(tuples=[[{ 0 }]]), type = RecordType(INTEGER ZERO)
EnumerableCalc(expr#0=[{inputs}], expr#1=[30], expr#2=[40],
expr#3=[ARRAY($t1, $t2)], EXPR$0=[$t3]), type = RecordType(INTEGER ARRAY EXPR$0)
EnumerableValues(tuples=[[{ 0 }]]), type = RecordType(INTEGER ZERO)
EnumerableUncollect(withOrdinality=[true]), type = RecordType(INTEGER EXPR$0,
INTEGER ORDINALITY)
EnumerableUnion(all=[true]), type = RecordType(INTEGER ARRAY EXPR$0)
EnumerableCalc(expr#0=[{inputs}], expr#1=[$SLICE($t0)], EXPR$0=[$t1]), type
= RecordType(INTEGER MULTISET EXPR$0)
EnumerableCollect(field=[EXPR$0]), type = RecordType(RecordType(INTEGER
ROW_VALUE) MULTISET EXPR$0)
EnumerableValues(tuples=[[{ 10 }, { 20 }]]), type = RecordType(INTEGER
ROW_VALUE)
EnumerableCalc(expr#0=[{inputs}], expr#1=[30], expr#2=[40],
expr#3=[ARRAY($t1, $t2)], EXPR$0=[$t3]), type = RecordType(INTEGER ARRAY EXPR$0)
EnumerableValues(tuples=[[{ 0 }]]), type = RecordType(INTEGER ZERO)
{noformat}
Part of the stacktrace of the exception is:
{code:java}
Cannot apply 'UNNEST' to arguments of type 'UNNEST()'. Supported form(s): 'UNNEST()'
'UNNEST()'
'UNNEST()'
UNNEST()
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:463)
at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:839)
at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:824)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:4905)
at
org.apache.calcite.sql.SqlCallBinding.newValidationSignatureError(SqlCallBinding.java:280)
at
org.apache.calcite.sql.type.CompositeOperandTypeChecker.checkOperandTypes(CompositeOperandTypeChecker.java:261)
at
org.apache.calcite.sql.SqlOperator.checkOperandTypes(SqlOperator.java:668)
at
org.apache.calcite.sql.SqlOperator.validateOperands(SqlOperator.java:432)
at
org.apache.calcite.sql.validate.UnnestNamespace.validateImpl(UnnestNamespace.java:66)
at
org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:1009)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:969)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateUnnest(SqlValidatorImpl.java:3171)
at
[jira] [Assigned] (CALCITE-3567) UNNEST(RECORDTYPE(MAP)) not supported
[
https://issues.apache.org/jira/browse/CALCITE-3567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin reassigned CALCITE-3567:
Assignee: Wang Yanlin
> UNNEST(RECORDTYPE(MAP)) not supported
> -
>
> Key: CALCITE-3567
> URL: https://issues.apache.org/jira/browse/CALCITE-3567
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Major
>
> UNNEST(RECORDTYPE(ARRAY)) and UNNEST(RECORDTYPE(MULTISET)) works well, but
> UNNEST(RECORDTYPE(MAP)) is not supported.
> {code:java}
> // JdbcTest
> @Test public void testUnnestRecordType() {
> // unnest(RecordType(Array))
> CalciteAssert.that()
> .query("select * from unnest\n"
> + "(select t.x from (values array[10, 20], array[30, 40]) as
> t(x))\n"
> + " with ordinality as t(a, o)")
> .returnsUnordered("A=10; O=1", "A=20; O=2",
> "A=30; O=1", "A=40; O=2");
> // unnest(RecordType(Multiset))
> CalciteAssert.that()
> .query("select * from unnest\n"
> + "(select t.x from (values multiset[10, 20], array[30, 40]) as
> t(x))\n"
> + " with ordinality as t(a, o)")
> .returnsUnordered("A=10; O=1", "A=20; O=2",
> "A=30; O=1", "A=40; O=2");
> // unnest(RecordType(Map))
> CalciteAssert.that()
> .query("select * from unnest\n"
> + "(select t.x from (values map['a', 20, 'b', 30], map['c', 40])
> as t(x))\n"
> + " with ordinality as t(a, b, o)")
> .returnsUnordered("A=a; B=20; O=1", "A=B; B=30; O=2",
> "A=c; B=40; O=1");
> }
> {code}
> In the case, test for *unnest(RecordType(Array))* and
> *unnest(RecordType(Multiset))* success, but got exception for
> *unnest(RecordType(Map))*.
> For the first two test of *unnest(RecordType(Array))* and
> *unnest(RecordType(Multiset))*, the relnode tree with type is like this
> {noformat}
> EnumerableUncollect(withOrdinality=[true]), type = RecordType(INTEGER EXPR$0,
> INTEGER ORDINALITY)
> EnumerableUnion(all=[true]), type = RecordType(INTEGER ARRAY EXPR$0)
> EnumerableCalc(expr#0=[{inputs}], expr#1=[10], expr#2=[20],
> expr#3=[ARRAY($t1, $t2)], EXPR$0=[$t3]), type = RecordType(INTEGER ARRAY
> EXPR$0)
> EnumerableValues(tuples=[[{ 0 }]]), type = RecordType(INTEGER ZERO)
> EnumerableCalc(expr#0=[{inputs}], expr#1=[30], expr#2=[40],
> expr#3=[ARRAY($t1, $t2)], EXPR$0=[$t3]), type = RecordType(INTEGER ARRAY
> EXPR$0)
> EnumerableValues(tuples=[[{ 0 }]]), type = RecordType(INTEGER ZERO)
> EnumerableUncollect(withOrdinality=[true]), type = RecordType(INTEGER EXPR$0,
> INTEGER ORDINALITY)
> EnumerableUnion(all=[true]), type = RecordType(INTEGER ARRAY EXPR$0)
> EnumerableCalc(expr#0=[{inputs}], expr#1=[$SLICE($t0)], EXPR$0=[$t1]),
> type = RecordType(INTEGER MULTISET EXPR$0)
> EnumerableCollect(field=[EXPR$0]), type = RecordType(RecordType(INTEGER
> ROW_VALUE) MULTISET EXPR$0)
> EnumerableValues(tuples=[[{ 10 }, { 20 }]]), type =
> RecordType(INTEGER ROW_VALUE)
> EnumerableCalc(expr#0=[{inputs}], expr#1=[30], expr#2=[40],
> expr#3=[ARRAY($t1, $t2)], EXPR$0=[$t3]), type = RecordType(INTEGER ARRAY
> EXPR$0)
> EnumerableValues(tuples=[[{ 0 }]]), type = RecordType(INTEGER ZERO)
> {noformat}
> Part of the stacktrace of the exception is:
> {code:java}
> Cannot apply 'UNNEST' to arguments of type 'UNNEST( INTEGER) MAP X)>)'. Supported form(s): 'UNNEST()'
> 'UNNEST()'
> 'UNNEST()'
> UNNEST()
> 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:463)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:839)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:824)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:4905)
> at
> org.apache.calcite.sql.SqlCallBinding.newValidationSignatureError(SqlCallBinding.java:280)
> at
> org.apache.calcite.sql.type.CompositeOperandTypeChecker.checkOperandTypes(CompositeOperandTypeChecker.java:261)
> at
> org.apache.calcite.sql.SqlOperator.checkOperandTypes(SqlOperator.java:668)
> at
> org.apache.calcite.sql.SqlOperator.validateOperands(SqlOperator.java:432)
> at
> org.apache.calcite.sql.validate.UnnestNamespace.validateImpl(UnnestNamespace.java:66)
> at
>
[jira] [Updated] (CALCITE-3566) Support EnumerableIntersect and EnumerableMinus convert to Logical
[ https://issues.apache.org/jira/browse/CALCITE-3566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-3566: Labels: pull-request-available (was: ) > Support EnumerableIntersect and EnumerableMinus convert to Logical > -- > > Key: CALCITE-3566 > URL: https://issues.apache.org/jira/browse/CALCITE-3566 > Project: Calcite > Issue Type: Wish >Reporter: xzh_dz >Priority: Minor > Labels: pull-request-available > > In ToLogicalConverter, EnumerableIntersect and EnumerableMinus can not > convert to Logical currently, this PR supports this transformation. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-3566) Support EnumerableIntersect and EnumerableMinus convert to Logical
xzh_dz created CALCITE-3566: --- Summary: Support EnumerableIntersect and EnumerableMinus convert to Logical Key: CALCITE-3566 URL: https://issues.apache.org/jira/browse/CALCITE-3566 Project: Calcite Issue Type: Wish Reporter: xzh_dz In ToLogicalConverter, EnumerableIntersect and EnumerableMinus can not convert to Logical currently, this PR supports this transformation. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CALCITE-3536) NPE when executing plan with Coalesce due to wrong NullAs strategy
[
https://issues.apache.org/jira/browse/CALCITE-3536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stamatis Zampetakis resolved CALCITE-3536.
--
Fix Version/s: 1.22.0
Resolution: Fixed
Fixed in
[0e16fe375f797e498c0039fc7cffecfd0dc9bc3d|https://github.com/apache/calcite/commit/0e16fe375f797e498c0039fc7cffecfd0dc9bc3d].
I simplified a bit the test and changed the commit message to be easier to
understand by people that are not familiar with Calcite internals. Thanks for
the PR [~jinxing6...@126.com]!
> NPE when executing plan with Coalesce due to wrong NullAs strategy
> --
>
> Key: CALCITE-3536
> URL: https://issues.apache.org/jira/browse/CALCITE-3536
> Project: Calcite
> Issue Type: Bug
>Reporter: Jin Xing
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.22.0
>
> Time Spent: 3h 40m
> Remaining Estimate: 0h
>
> Currently, COALESCE expression specified in sql string will be rewrite to
> CASE by SqlValidator [1], thus CoalesceImplementor is almost no use. But it
> is actually used somewhere, for example Sum0Splitter. When running
> AggregateRemove and split expression SUM0, a COALESCE is actually created and
> no chance to be rewrite to CASE anymore.
> In current code, CoalesceImplementor doesn't handle NullAs properly by
> semantics.
> If we disable the rewrite from COALESCE to CASE in Validator and run below
> sql in JDBC Test:
> {code:java}
> select grocery_sqft from store where coalesce(grocery_sqft, 0) >= 2{code}
> We will get below exception:
> {code:java}
> Caused by: java.lang.RuntimeException: Error while compiling generated Java
> code:
> public org.apache.calcite.linq4j.Enumerable bind(final
> org.apache.calcite.DataContext root) {
> final org.apache.calcite.linq4j.Enumerable _inputEnumerable =
> org.apache.calcite.schema.Schemas.queryable(root,
> root.getRootSchema().getSubSchema("foodmart2"), java.lang.Object[].class,
> "store").asEnumerable();
> return new org.apache.calcite.linq4j.AbstractEnumerable(){
> public org.apache.calcite.linq4j.Enumerator enumerator() {
> return new org.apache.calcite.linq4j.Enumerator(){
> public final org.apache.calcite.linq4j.Enumerator inputEnumerator
> = _inputEnumerable.enumerator();
> public void reset() {
> inputEnumerator.reset();
> }public boolean moveNext() {
> while (inputEnumerator.moveNext()) {
> final Integer inp16_ = (Integer) ((Object[])
> inputEnumerator.current())[16];
> if ((inp16_ ? inp16_.intValue() : 0) >= 2) {
> return true;
> }
> }
> return false;
> }public void close() {
> inputEnumerator.close();
> }public Object current() {
> return (Integer) ((Object[]) inputEnumerator.current())[16];
> } };
> }};
> }
> at org.apache.calcite.avatica.Helper.wrap(Helper.java:37)
> at org.apache.calcite.avatica.Helper.wrap(Helper.java:37)
> at
> org.apache.calcite.adapter.enumerable.EnumerableInterpretable.toBindable(EnumerableInterpretable.java:128)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl$CalcitePreparingStmt.implement(CalcitePrepareImpl.java:)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:332)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:231)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:638)
>
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:502)
>
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:472)
>
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:231)
>
> at
> org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:550)
>
> at
> org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:675)
>
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:156)
> ... 29 more
> Caused by: org.codehaus.commons.compiler.CompileException: Line 14, Column
> 28: Not a boolean expression
> at org.codehaus.janino.UnitCompiler.compileError(UnitCompiler.java:12211)
> at org.codehaus.janino.UnitCompiler.compileBoolean2(UnitCompiler.java:3994)
> at org.codehaus.janino.UnitCompiler.access$6300(UnitCompiler.java:215){code}
> This issue was found when I try to resolve CALCITE-3124 and CALCITE-3505
> [1]
> [https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/validate/SqlValidatorImpl.java#L1210]
--
This message was sent
[jira] [Updated] (CALCITE-3536) NPE when executing plan with Coalesce due to wrong NullAs strategy
[
https://issues.apache.org/jira/browse/CALCITE-3536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stamatis Zampetakis updated CALCITE-3536:
-
Summary: NPE when executing plan with Coalesce due to wrong NullAs strategy
(was: "if(null)" not compiling in CoalesceImplementor)
> NPE when executing plan with Coalesce due to wrong NullAs strategy
> --
>
> Key: CALCITE-3536
> URL: https://issues.apache.org/jira/browse/CALCITE-3536
> Project: Calcite
> Issue Type: Bug
>Reporter: Jin Xing
>Priority: Major
> Labels: pull-request-available
> Time Spent: 3h 40m
> Remaining Estimate: 0h
>
> Currently, COALESCE expression specified in sql string will be rewrite to
> CASE by SqlValidator [1], thus CoalesceImplementor is almost no use. But it
> is actually used somewhere, for example Sum0Splitter. When running
> AggregateRemove and split expression SUM0, a COALESCE is actually created and
> no chance to be rewrite to CASE anymore.
> In current code, CoalesceImplementor doesn't handle NullAs properly by
> semantics.
> If we disable the rewrite from COALESCE to CASE in Validator and run below
> sql in JDBC Test:
> {code:java}
> select grocery_sqft from store where coalesce(grocery_sqft, 0) >= 2{code}
> We will get below exception:
> {code:java}
> Caused by: java.lang.RuntimeException: Error while compiling generated Java
> code:
> public org.apache.calcite.linq4j.Enumerable bind(final
> org.apache.calcite.DataContext root) {
> final org.apache.calcite.linq4j.Enumerable _inputEnumerable =
> org.apache.calcite.schema.Schemas.queryable(root,
> root.getRootSchema().getSubSchema("foodmart2"), java.lang.Object[].class,
> "store").asEnumerable();
> return new org.apache.calcite.linq4j.AbstractEnumerable(){
> public org.apache.calcite.linq4j.Enumerator enumerator() {
> return new org.apache.calcite.linq4j.Enumerator(){
> public final org.apache.calcite.linq4j.Enumerator inputEnumerator
> = _inputEnumerable.enumerator();
> public void reset() {
> inputEnumerator.reset();
> }public boolean moveNext() {
> while (inputEnumerator.moveNext()) {
> final Integer inp16_ = (Integer) ((Object[])
> inputEnumerator.current())[16];
> if ((inp16_ ? inp16_.intValue() : 0) >= 2) {
> return true;
> }
> }
> return false;
> }public void close() {
> inputEnumerator.close();
> }public Object current() {
> return (Integer) ((Object[]) inputEnumerator.current())[16];
> } };
> }};
> }
> at org.apache.calcite.avatica.Helper.wrap(Helper.java:37)
> at org.apache.calcite.avatica.Helper.wrap(Helper.java:37)
> at
> org.apache.calcite.adapter.enumerable.EnumerableInterpretable.toBindable(EnumerableInterpretable.java:128)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl$CalcitePreparingStmt.implement(CalcitePrepareImpl.java:)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:332)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:231)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:638)
>
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:502)
>
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:472)
>
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:231)
>
> at
> org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:550)
>
> at
> org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:675)
>
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:156)
> ... 29 more
> Caused by: org.codehaus.commons.compiler.CompileException: Line 14, Column
> 28: Not a boolean expression
> at org.codehaus.janino.UnitCompiler.compileError(UnitCompiler.java:12211)
> at org.codehaus.janino.UnitCompiler.compileBoolean2(UnitCompiler.java:3994)
> at org.codehaus.janino.UnitCompiler.access$6300(UnitCompiler.java:215){code}
> This issue was found when I try to resolve CALCITE-3124 and CALCITE-3505
> [1]
> [https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/validate/SqlValidatorImpl.java#L1210]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3561) Support using unnest in Interpreter
[
https://issues.apache.org/jira/browse/CALCITE-3561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-3561:
Labels: pull-request-available (was: )
> Support using unnest in Interpreter
> ---
>
> Key: CALCITE-3561
> URL: https://issues.apache.org/jira/browse/CALCITE-3561
> Project: Calcite
> Issue Type: Improvement
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Major
> Labels: pull-request-available
>
> Using unnest in Interpreter will cause exception,
> {code:java}
> // InterpreterTest
> @Test public void testInterpretUnnest() throws Exception {
> final String sql = "select * from unnest(multiset[1, 2])";
> sql(sql).returnsRows("[1]", "[2]");
> }
> {code}
> got
> {code:java}
> java.lang.AssertionError: interpreter: no implementation for class
> org.apache.calcite.rel.core.Uncollect
> at
> org.apache.calcite.interpreter.Interpreter$CompilerImpl.visit(Interpreter.java:463)
> at
> org.apache.calcite.interpreter.Nodes$CoreCompiler.visit(Nodes.java:44)
> at org.apache.calcite.rel.SingleRel.childrenAccept(SingleRel.java:72)
> at
> org.apache.calcite.interpreter.Interpreter$CompilerImpl.visit(Interpreter.java:450)
> at
> org.apache.calcite.interpreter.Nodes$CoreCompiler.visit(Nodes.java:44)
> at
> org.apache.calcite.interpreter.Interpreter$CompilerImpl.visitRoot(Interpreter.java:408)
> at
> org.apache.calcite.interpreter.Interpreter.(Interpreter.java:89)
> at
> org.apache.calcite.test.InterpreterTest$Sql.returnsRows(InterpreterTest.java:121)
> at
> org.apache.calcite.test.InterpreterTest$Sql.returnsRows(InterpreterTest.java:105)
> at
> org.apache.calcite.test.InterpreterTest.testInterpretUnnest(InterpreterTest.java:446)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> {code}
> Add support to use unnest in Interpreter.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3565) Explicitly cast assignable operand types to decimal for udf
[
https://issues.apache.org/jira/browse/CALCITE-3565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Feng Zhu updated CALCITE-3565:
--
Description:
Type is assignable conceptually, but in the runtime phase, explicite cast is
still required.
For example, according to _*SqlTypeAssignmentRules*_, *_ST_MakePoint(Decimal,
Decimal)_* also accepts operands with (_Integer_, _Decimal_) types, because
Decimal is assignable from Integer.
{code:java}
@Test public void test1() {
final String sql = "SELECT ST_MakePoint(1, 2.1)";
CalciteAssert.that()
.with(CalciteAssert.Config.GEO)
.query(sql)
.returns("EXPR$0={\"x\":1,\"y\":2.1}\n");
}
{code}
We will get:
{code:java}
org.codehaus.commons.compiler.CompileException: Line 22, Column 124: No
applicable constructor/method found for actual parameters "int,
java.math.BigDecimal"; candidates are: "public static
org.apache.calcite.runtime.GeoFunctions$Geom
org.apache.calcite.runtime.GeoFunctions.ST_MakePoint(java.math.BigDecimal,
java.math.BigDecimal, java.math.BigDecimal)", "public static
org.apache.calcite.runtime.GeoFunctions$Geom
org.apache.calcite.runtime.GeoFunctions.ST_MakePoint(java.math.BigDecimal,
java.math.BigDecimal)"
at org.codehaus.janino.UnitCompiler.compileError(UnitCompiler.java:12211)
at
org.codehaus.janino.UnitCompiler.findMostSpecificIInvocable(UnitCompiler.java:9263)
at org.codehaus.janino.UnitCompiler.findIMethod(UnitCompiler.java:9123)
at org.codehaus.janino.UnitCompiler.findIMethod(UnitCompiler.java:9025)
at org.codehaus.janino.UnitCompiler.compileGet2(UnitCompiler.java:5062)
at org.codehaus.janino.UnitCompiler.access$9100(UnitCompiler.java:215){code}
> Explicitly cast assignable operand types to decimal for udf
> ---
>
> Key: CALCITE-3565
> URL: https://issues.apache.org/jira/browse/CALCITE-3565
> Project: Calcite
> Issue Type: Sub-task
>Reporter: Feng Zhu
>Assignee: Feng Zhu
>Priority: Major
>
> Type is assignable conceptually, but in the runtime phase, explicite cast is
> still required.
> For example, according to _*SqlTypeAssignmentRules*_,
> *_ST_MakePoint(Decimal, Decimal)_* also accepts operands with (_Integer_,
> _Decimal_) types, because Decimal is assignable from Integer.
> {code:java}
> @Test public void test1() {
> final String sql = "SELECT ST_MakePoint(1, 2.1)";
> CalciteAssert.that()
> .with(CalciteAssert.Config.GEO)
> .query(sql)
> .returns("EXPR$0={\"x\":1,\"y\":2.1}\n");
> }
> {code}
> We will get:
> {code:java}
> org.codehaus.commons.compiler.CompileException: Line 22, Column 124: No
> applicable constructor/method found for actual parameters "int,
> java.math.BigDecimal"; candidates are: "public static
> org.apache.calcite.runtime.GeoFunctions$Geom
> org.apache.calcite.runtime.GeoFunctions.ST_MakePoint(java.math.BigDecimal,
> java.math.BigDecimal, java.math.BigDecimal)", "public static
> org.apache.calcite.runtime.GeoFunctions$Geom
> org.apache.calcite.runtime.GeoFunctions.ST_MakePoint(java.math.BigDecimal,
> java.math.BigDecimal)"
> at org.codehaus.janino.UnitCompiler.compileError(UnitCompiler.java:12211)
> at
> org.codehaus.janino.UnitCompiler.findMostSpecificIInvocable(UnitCompiler.java:9263)
> at org.codehaus.janino.UnitCompiler.findIMethod(UnitCompiler.java:9123)
> at org.codehaus.janino.UnitCompiler.findIMethod(UnitCompiler.java:9025)
> at org.codehaus.janino.UnitCompiler.compileGet2(UnitCompiler.java:5062)
> at org.codehaus.janino.UnitCompiler.access$9100(UnitCompiler.java:215){code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-3565) Explicitly cast assignable operand types to decimal for udf
Feng Zhu created CALCITE-3565: - Summary: Explicitly cast assignable operand types to decimal for udf Key: CALCITE-3565 URL: https://issues.apache.org/jira/browse/CALCITE-3565 Project: Calcite Issue Type: Sub-task Reporter: Feng Zhu Assignee: Feng Zhu -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-3563) Convert function operand type to match implementation if necessary in runtime
[
https://issues.apache.org/jira/browse/CALCITE-3563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Feng Zhu updated CALCITE-3563:
--
Description:
Sub-task targets on following issue.
(1)Validation phase allows a wide range of operand types, but the runtime
implementation does not cover all cases.
For example, _*SqlFunction(MOD)*_ adopts
_*OperandTypes.EXACT_NUMERIC_EXACT_NUMERIC*_.
{code:java}
@Test public void test0() {
final String sql = "SELECT mod(12.5, cast(1 as bigint))";
CalciteAssert.that()
.query(sql)
.returns("EXPR$0=0.5\n");
}{code}
We will get:
{code:java}
java.lang.RuntimeException: while resolving method 'mod[class
java.math.BigDecimal, long]' in class class
org.apache.calcite.runtime.SqlFunctions
at org.apache.calcite.linq4j.tree.Types.lookupMethod(Types.java:323)
at org.apache.calcite.linq4j.tree.Expressions.call(Expressions.java:445)
at
org.apache.calcite.adapter.enumerable.RexImpTable$MethodNameImplementor.implement(RexImpTable.java:2253)
at
org.apache.calcite.adapter.enumerable.RexImpTable.implementCall(RexImpTable.java:1195){code}
was:
Sub-task targets on following issues.
(1)Validation phase allows a wide range of operand types, but the runtime
implementation does not cover all cases.
For example, _*SqlFunction(MOD)*_ adopts
_*OperandTypes.EXACT_NUMERIC_EXACT_NUMERIC*_.
{code:java}
@Test public void test0() {
final String sql = "SELECT mod(12.5, cast(1 as bigint))";
CalciteAssert.that()
.query(sql)
.returns("EXPR$0=0.5\n");
}{code}
We will get:
{code:java}
java.lang.RuntimeException: while resolving method 'mod[class
java.math.BigDecimal, long]' in class class
org.apache.calcite.runtime.SqlFunctions
at org.apache.calcite.linq4j.tree.Types.lookupMethod(Types.java:323)
at org.apache.calcite.linq4j.tree.Expressions.call(Expressions.java:445)
at
org.apache.calcite.adapter.enumerable.RexImpTable$MethodNameImplementor.implement(RexImpTable.java:2253)
at
org.apache.calcite.adapter.enumerable.RexImpTable.implementCall(RexImpTable.java:1195){code}
(2)Type is assignable conceptually, but in the runtime phase, explicite cast is
still required.
For example, according to _*SqlTypeAssignmentRules*_, *_ST_MakePoint(Decimal,
Decimal)_* also accepts operands with (_Integer_, _Decimal_) types, because
Decimal is assignable from Integer.
{code:java}
@Test public void test1() {
final String sql = "SELECT ST_MakePoint(1, 2.1)";
CalciteAssert.that()
.with(CalciteAssert.Config.GEO)
.query(sql)
.returns("EXPR$0={\"x\":1,\"y\":2.1}\n");
}
{code}
We will get:
{code:java}
org.codehaus.commons.compiler.CompileException: Line 22, Column 124: No
applicable constructor/method found for actual parameters "int,
java.math.BigDecimal"; candidates are: "public static
org.apache.calcite.runtime.GeoFunctions$Geom
org.apache.calcite.runtime.GeoFunctions.ST_MakePoint(java.math.BigDecimal,
java.math.BigDecimal, java.math.BigDecimal)", "public static
org.apache.calcite.runtime.GeoFunctions$Geom
org.apache.calcite.runtime.GeoFunctions.ST_MakePoint(java.math.BigDecimal,
java.math.BigDecimal)"
at org.codehaus.janino.UnitCompiler.compileError(UnitCompiler.java:12211)
at
org.codehaus.janino.UnitCompiler.findMostSpecificIInvocable(UnitCompiler.java:9263)
at org.codehaus.janino.UnitCompiler.findIMethod(UnitCompiler.java:9123)
at org.codehaus.janino.UnitCompiler.findIMethod(UnitCompiler.java:9025)
at org.codehaus.janino.UnitCompiler.compileGet2(UnitCompiler.java:5062)
at org.codehaus.janino.UnitCompiler.access$9100(UnitCompiler.java:215){code}
> Convert function operand type to match implementation if necessary in runtime
> -
>
> Key: CALCITE-3563
> URL: https://issues.apache.org/jira/browse/CALCITE-3563
> Project: Calcite
> Issue Type: Sub-task
> Components: core
>Reporter: Feng Zhu
>Assignee: Feng Zhu
>Priority: Major
>
> Sub-task targets on following issue.
>
> (1)Validation phase allows a wide range of operand types, but the runtime
> implementation does not cover all cases.
> For example, _*SqlFunction(MOD)*_ adopts
> _*OperandTypes.EXACT_NUMERIC_EXACT_NUMERIC*_.
> {code:java}
> @Test public void test0() {
> final String sql = "SELECT mod(12.5, cast(1 as bigint))";
> CalciteAssert.that()
> .query(sql)
> .returns("EXPR$0=0.5\n");
> }{code}
> We will get:
> {code:java}
> java.lang.RuntimeException: while resolving method 'mod[class
> java.math.BigDecimal, long]' in class class
> org.apache.calcite.runtime.SqlFunctions
> at org.apache.calcite.linq4j.tree.Types.lookupMethod(Types.java:323)
> at org.apache.calcite.linq4j.tree.Expressions.call(Expressions.java:445)
> at
> org.apache.calcite.adapter.enumerable.RexImpTable$MethodNameImplementor.implement(RexImpTable.java:2253)
>
[jira] [Updated] (CALCITE-3563) Convert function operand type to match implementation if necessary in runtime
[
https://issues.apache.org/jira/browse/CALCITE-3563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Feng Zhu updated CALCITE-3563:
--
Description:
Sub-task targets on following issues.
(1)Validation phase allows a wide range of operand types, but the runtime
implementation does not cover all cases.
For example, _*SqlFunction(MOD)*_ adopts
_*OperandTypes.EXACT_NUMERIC_EXACT_NUMERIC*_.
{code:java}
@Test public void test0() {
final String sql = "SELECT mod(12.5, cast(1 as bigint))";
CalciteAssert.that()
.query(sql)
.returns("EXPR$0=0.5\n");
}{code}
We will get:
{code:java}
java.lang.RuntimeException: while resolving method 'mod[class
java.math.BigDecimal, long]' in class class
org.apache.calcite.runtime.SqlFunctions
at org.apache.calcite.linq4j.tree.Types.lookupMethod(Types.java:323)
at org.apache.calcite.linq4j.tree.Expressions.call(Expressions.java:445)
at
org.apache.calcite.adapter.enumerable.RexImpTable$MethodNameImplementor.implement(RexImpTable.java:2253)
at
org.apache.calcite.adapter.enumerable.RexImpTable.implementCall(RexImpTable.java:1195){code}
(2)Type is assignable conceptually, but in the runtime phase, explicite cast is
still required.
For example, according to _*SqlTypeAssignmentRules*_, *_ST_MakePoint(Decimal,
Decimal)_* also accepts operands with (_Integer_, _Decimal_) types, because
Decimal is assignable from Integer.
{code:java}
@Test public void test1() {
final String sql = "SELECT ST_MakePoint(1, 2.1)";
CalciteAssert.that()
.with(CalciteAssert.Config.GEO)
.query(sql)
.returns("EXPR$0={\"x\":1,\"y\":2.1}\n");
}
{code}
We will get:
{code:java}
org.codehaus.commons.compiler.CompileException: Line 22, Column 124: No
applicable constructor/method found for actual parameters "int,
java.math.BigDecimal"; candidates are: "public static
org.apache.calcite.runtime.GeoFunctions$Geom
org.apache.calcite.runtime.GeoFunctions.ST_MakePoint(java.math.BigDecimal,
java.math.BigDecimal, java.math.BigDecimal)", "public static
org.apache.calcite.runtime.GeoFunctions$Geom
org.apache.calcite.runtime.GeoFunctions.ST_MakePoint(java.math.BigDecimal,
java.math.BigDecimal)"
at org.codehaus.janino.UnitCompiler.compileError(UnitCompiler.java:12211)
at
org.codehaus.janino.UnitCompiler.findMostSpecificIInvocable(UnitCompiler.java:9263)
at org.codehaus.janino.UnitCompiler.findIMethod(UnitCompiler.java:9123)
at org.codehaus.janino.UnitCompiler.findIMethod(UnitCompiler.java:9025)
at org.codehaus.janino.UnitCompiler.compileGet2(UnitCompiler.java:5062)
at org.codehaus.janino.UnitCompiler.access$9100(UnitCompiler.java:215){code}
was:
Sub-task targets on following issue.
(1)Validation phase allows a wide range of operand types, but the runtime
implementation does not cover all cases.
For example, _*SqlFunction(MOD)*_ adopts
_*OperandTypes.EXACT_NUMERIC_EXACT_NUMERIC*_.
{code:java}
@Test public void test0() {
final String sql = "SELECT mod(12.5, cast(1 as bigint))";
CalciteAssert.that()
.query(sql)
.returns("EXPR$0=0.5\n");
}{code}
We will get:
{code:java}
java.lang.RuntimeException: while resolving method 'mod[class
java.math.BigDecimal, long]' in class class
org.apache.calcite.runtime.SqlFunctions
at org.apache.calcite.linq4j.tree.Types.lookupMethod(Types.java:323)
at org.apache.calcite.linq4j.tree.Expressions.call(Expressions.java:445)
at
org.apache.calcite.adapter.enumerable.RexImpTable$MethodNameImplementor.implement(RexImpTable.java:2253)
at
org.apache.calcite.adapter.enumerable.RexImpTable.implementCall(RexImpTable.java:1195){code}
> Convert function operand type to match implementation if necessary in runtime
> -
>
> Key: CALCITE-3563
> URL: https://issues.apache.org/jira/browse/CALCITE-3563
> Project: Calcite
> Issue Type: Sub-task
> Components: core
>Reporter: Feng Zhu
>Assignee: Feng Zhu
>Priority: Major
>
> Sub-task targets on following issues.
>
> (1)Validation phase allows a wide range of operand types, but the runtime
> implementation does not cover all cases.
> For example, _*SqlFunction(MOD)*_ adopts
> _*OperandTypes.EXACT_NUMERIC_EXACT_NUMERIC*_.
> {code:java}
> @Test public void test0() {
> final String sql = "SELECT mod(12.5, cast(1 as bigint))";
> CalciteAssert.that()
> .query(sql)
> .returns("EXPR$0=0.5\n");
> }{code}
> We will get:
> {code:java}
> java.lang.RuntimeException: while resolving method 'mod[class
> java.math.BigDecimal, long]' in class class
> org.apache.calcite.runtime.SqlFunctions
> at org.apache.calcite.linq4j.tree.Types.lookupMethod(Types.java:323)
> at org.apache.calcite.linq4j.tree.Expressions.call(Expressions.java:445)
> at
> org.apache.calcite.adapter.enumerable.RexImpTable$MethodNameImplementor.implement(RexImpTable.java:2253)
> at
[jira] [Updated] (CALCITE-3562) Unify function's operands type check logic in validation and behavior in runtime
[
https://issues.apache.org/jira/browse/CALCITE-3562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Feng Zhu updated CALCITE-3562:
--
Description:
Current now, there are many issues caused by inconsistency between validator
and runtime phase. To summarize:
(1)Validation phase allows a wide range of operand types, but the runtime
implementation does not cover all cases.
For example, _*SqlFunction(MOD)*_ adopts
_*OperandTypes.EXACT_NUMERIC_EXACT_NUMERIC*_.
{code:java}
@Test public void test0() {
final String sql = "SELECT mod(12.5, cast(1 as bigint))";
CalciteAssert.that()
.query(sql)
.returns("EXPR$0=0.5\n");
}{code}
We will get:
{code:java}
java.lang.RuntimeException: while resolving method 'mod[class
java.math.BigDecimal, long]' in class class
org.apache.calcite.runtime.SqlFunctions
at org.apache.calcite.linq4j.tree.Types.lookupMethod(Types.java:323)
at org.apache.calcite.linq4j.tree.Expressions.call(Expressions.java:445)
at
org.apache.calcite.adapter.enumerable.RexImpTable$MethodNameImplementor.implement(RexImpTable.java:2253)
at
org.apache.calcite.adapter.enumerable.RexImpTable.implementCall(RexImpTable.java:1195){code}
(2)Type is assignable conceptually, but in the runtime phase, explicite cast is
still required.
For example, according to _*SqlTypeAssignmentRules*_, *_ST_MakePoint(Decimal,
Decimal)_* also accepts operands with (_Integer_, _Decimal_) types, because
Decimal is assignable from Integer.
{code:java}
@Test public void test1() {
final String sql = "SELECT ST_MakePoint(1, 2.1)";
CalciteAssert.that()
.with(CalciteAssert.Config.GEO)
.query(sql)
.returns("EXPR$0={\"x\":1,\"y\":2.1}\n");
}
{code}
We will get:
{code:java}
org.codehaus.commons.compiler.CompileException: Line 22, Column 124: No
applicable constructor/method found for actual parameters "int,
java.math.BigDecimal"; candidates are: "public static
org.apache.calcite.runtime.GeoFunctions$Geom
org.apache.calcite.runtime.GeoFunctions.ST_MakePoint(java.math.BigDecimal,
java.math.BigDecimal, java.math.BigDecimal)", "public static
org.apache.calcite.runtime.GeoFunctions$Geom
org.apache.calcite.runtime.GeoFunctions.ST_MakePoint(java.math.BigDecimal,
java.math.BigDecimal)"
at org.codehaus.janino.UnitCompiler.compileError(UnitCompiler.java:12211)
at
org.codehaus.janino.UnitCompiler.findMostSpecificIInvocable(UnitCompiler.java:9263)
at org.codehaus.janino.UnitCompiler.findIMethod(UnitCompiler.java:9123)
at org.codehaus.janino.UnitCompiler.findIMethod(UnitCompiler.java:9025)
at org.codehaus.janino.UnitCompiler.compileGet2(UnitCompiler.java:5062)
at org.codehaus.janino.UnitCompiler.access$9100(UnitCompiler.java:215){code}
(3)For some functions, it is too late to fail the query in runtime phase.
For example: _*RAND_INTEGER*_ adopts _*OperandTypes.or(OperandTypes.NUMERIC,
OperandTypes.NUMERIC_NUMERIC)*_
{code:java}
@Test public void test2() {
final String sql = "SELECT rand_integer(1.1, 2)";
CalciteAssert.that()
.query(sql)
.planContains("xyxyx")
.returns("EXPR$0={\"x\":1,\"y\":2.1}\n");
}{code}
We will get:
{code:java}
org.codehaus.commons.compiler.CompileException: Line 22, Column 100: No
applicable constructor/method found for actual parameters
"java.math.BigDecimal, int"; candidates are: "public int
org.apache.calcite.runtime.RandomFunction.randIntegerSeed(int, int)"
at org.codehaus.janino.UnitCompiler.compileError(UnitCompiler.java:12211)
at
org.codehaus.janino.UnitCompiler.findMostSpecificIInvocable(UnitCompiler.java:9263)
at org.codehaus.janino.UnitCompiler.findIMethod(UnitCompiler.java:9123){code}
*How to fix?*
>From my personal view, for case (1) and (2), we need to fix it in runtime
>layer with a "try-best" mechanism to convert operand type to match the
>implementation.
The difference between them: case(1) is builtin function, we cannot get exact
argument types, while case(2) is udf.
For case(3), it seems more suitable to fix in Validation phase.
was:
Current now, there are many issues caused by inconsistency between validator
and runtime phase. To summarize:
(1)Validation phase allows a wide range of operand types, but the runtime
implementation does not cover all cases.
For example, _*SqlFunction(MOD)*_ adopts
_*OperandTypes.EXACT_NUMERIC_EXACT_NUMERIC*_.
{code:java}
@Test public void test0() {
final String sql = "SELECT mod(12.5, cast(1 as bigint))";
CalciteAssert.that()
.query(sql)
.returns("EXPR$0=0.5\n");
}{code}
We will get:
{code:java}
java.lang.RuntimeException: while resolving method 'mod[class
java.math.BigDecimal, long]' in class class
org.apache.calcite.runtime.SqlFunctions
at org.apache.calcite.linq4j.tree.Types.lookupMethod(Types.java:323)
at org.apache.calcite.linq4j.tree.Expressions.call(Expressions.java:445)
at
org.apache.calcite.adapter.enumerable.RexImpTable$MethodNameImplementor.implement(RexImpTable.java:2253)
at
[jira] [Updated] (CALCITE-3477) Decimal type should not be assigned from other types
[
https://issues.apache.org/jira/browse/CALCITE-3477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Feng Zhu updated CALCITE-3477:
--
Issue Type: Bug (was: Task)
> Decimal type should not be assigned from other types
>
>
> Key: CALCITE-3477
> URL: https://issues.apache.org/jira/browse/CALCITE-3477
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Kirils Mensikovs
>Assignee: Feng Zhu
>Priority: Major
> Labels: geospatial, pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Geospatial function with integer parameter fails. The expected behavior is to
> cast automatically all number values to BigDecimal.
> {{Example: 'select ST_MAKEPOINT(1.0, 1)'}}
> Return:
> {code:java}
> Error: Error while executing SQL "select ST_MAKEPOINT(1.0, 1)": Error while
> compiling generated Java code:
> public org.apache.calcite.linq4j.Enumerable bind(final
> org.apache.calcite.DataContext root) {
> final org.apache.calcite.linq4j.Enumerable _inputEnumerable =
> org.apache.calcite.linq4j.Linq4j.asEnumerable(new Integer[] {
> 0});
> return new org.apache.calcite.linq4j.AbstractEnumerable(){
> public org.apache.calcite.linq4j.Enumerator enumerator() {
> return new org.apache.calcite.linq4j.Enumerator(){
> public final org.apache.calcite.linq4j.Enumerator inputEnumerator
> = _inputEnumerable.enumerator();
> public void reset() {
> inputEnumerator.reset();
> }
> public boolean moveNext() {
> return inputEnumerator.moveNext();
> }
> public void close() {
> inputEnumerator.close();
> }
> public Object current() {
> final java.math.BigDecimal v =
> $L4J$C$new_java_math_BigDecimal_1_0_;
> return org.apache.calcite.runtime.GeoFunctions.ST_MakePoint(v,
> 1);
> }
> static final java.math.BigDecimal
> $L4J$C$new_java_math_BigDecimal_1_0_ = new java.math.BigDecimal(
> "1.0");
> };
> }
> };
> }
> public Class getElementType() {
> return org.apache.calcite.runtime.GeoFunctions.Geom.class;
> } (state=,code=0)
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3477) Decimal type should not be assigned from other types
[
https://issues.apache.org/jira/browse/CALCITE-3477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Feng Zhu updated CALCITE-3477:
--
Issue Type: Task (was: Bug)
> Decimal type should not be assigned from other types
>
>
> Key: CALCITE-3477
> URL: https://issues.apache.org/jira/browse/CALCITE-3477
> Project: Calcite
> Issue Type: Task
> Components: core
>Reporter: Kirils Mensikovs
>Assignee: Feng Zhu
>Priority: Major
> Labels: geospatial, pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Geospatial function with integer parameter fails. The expected behavior is to
> cast automatically all number values to BigDecimal.
> {{Example: 'select ST_MAKEPOINT(1.0, 1)'}}
> Return:
> {code:java}
> Error: Error while executing SQL "select ST_MAKEPOINT(1.0, 1)": Error while
> compiling generated Java code:
> public org.apache.calcite.linq4j.Enumerable bind(final
> org.apache.calcite.DataContext root) {
> final org.apache.calcite.linq4j.Enumerable _inputEnumerable =
> org.apache.calcite.linq4j.Linq4j.asEnumerable(new Integer[] {
> 0});
> return new org.apache.calcite.linq4j.AbstractEnumerable(){
> public org.apache.calcite.linq4j.Enumerator enumerator() {
> return new org.apache.calcite.linq4j.Enumerator(){
> public final org.apache.calcite.linq4j.Enumerator inputEnumerator
> = _inputEnumerable.enumerator();
> public void reset() {
> inputEnumerator.reset();
> }
> public boolean moveNext() {
> return inputEnumerator.moveNext();
> }
> public void close() {
> inputEnumerator.close();
> }
> public Object current() {
> final java.math.BigDecimal v =
> $L4J$C$new_java_math_BigDecimal_1_0_;
> return org.apache.calcite.runtime.GeoFunctions.ST_MakePoint(v,
> 1);
> }
> static final java.math.BigDecimal
> $L4J$C$new_java_math_BigDecimal_1_0_ = new java.math.BigDecimal(
> "1.0");
> };
> }
> };
> }
> public Class getElementType() {
> return org.apache.calcite.runtime.GeoFunctions.Geom.class;
> } (state=,code=0)
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3563) Convert function operand type to match implementation if necessary in runtime
[
https://issues.apache.org/jira/browse/CALCITE-3563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Feng Zhu updated CALCITE-3563:
--
Description:
Sub-task targets on following issue.
(1)Validation phase allows a wide range of operand types, but the runtime
implementation does not cover all cases.
For example, _*SqlFunction(MOD)*_ adopts
_*OperandTypes.EXACT_NUMERIC_EXACT_NUMERIC*_.
{code:java}
@Test public void test0() {
final String sql = "SELECT mod(12.5, cast(1 as bigint))";
CalciteAssert.that()
.query(sql)
.returns("EXPR$0=0.5\n");
}{code}
We will get:
{code:java}
java.lang.RuntimeException: while resolving method 'mod[class
java.math.BigDecimal, long]' in class class
org.apache.calcite.runtime.SqlFunctions
at org.apache.calcite.linq4j.tree.Types.lookupMethod(Types.java:323)
at org.apache.calcite.linq4j.tree.Expressions.call(Expressions.java:445)
at
org.apache.calcite.adapter.enumerable.RexImpTable$MethodNameImplementor.implement(RexImpTable.java:2253)
at
org.apache.calcite.adapter.enumerable.RexImpTable.implementCall(RexImpTable.java:1195){code}
was:
Sub-task targets on following two kinds of issues.
(1)Validation phase allows a wide range of operand types, but the runtime
implementation does not cover all cases.
For example, _*SqlFunction(MOD)*_ adopts
_*OperandTypes.EXACT_NUMERIC_EXACT_NUMERIC*_.
{code:java}
@Test public void test0() {
final String sql = "SELECT mod(12.5, cast(1 as bigint))";
CalciteAssert.that()
.query(sql)
.returns("EXPR$0=0.5\n");
}{code}
We will get:
{code:java}
java.lang.RuntimeException: while resolving method 'mod[class
java.math.BigDecimal, long]' in class class
org.apache.calcite.runtime.SqlFunctions
at org.apache.calcite.linq4j.tree.Types.lookupMethod(Types.java:323)
at org.apache.calcite.linq4j.tree.Expressions.call(Expressions.java:445)
at
org.apache.calcite.adapter.enumerable.RexImpTable$MethodNameImplementor.implement(RexImpTable.java:2253)
at
org.apache.calcite.adapter.enumerable.RexImpTable.implementCall(RexImpTable.java:1195){code}
(2)Type is assignable conceptually, but in the runtime phase, explicite cast is
still required.
For example, according to _*SqlTypeAssignmentRules*_, *_ST_MakePoint(Decimal,
Decimal)_* also accepts operands with (_Integer_, _Decimal_) types, because
Decimal is assignable from Integer.
{code:java}
@Test public void test1() {
final String sql = "SELECT ST_MakePoint(1, 2.1)";
CalciteAssert.that()
.with(CalciteAssert.Config.GEO)
.query(sql)
.returns("EXPR$0={\"x\":1,\"y\":2.1}\n");
}
{code}
We will get:
{code:java}
org.codehaus.commons.compiler.CompileException: Line 22, Column 124: No
applicable constructor/method found for actual parameters "int,
java.math.BigDecimal"; candidates are: "public static
org.apache.calcite.runtime.GeoFunctions$Geom
org.apache.calcite.runtime.GeoFunctions.ST_MakePoint(java.math.BigDecimal,
java.math.BigDecimal, java.math.BigDecimal)", "public static
org.apache.calcite.runtime.GeoFunctions$Geom
org.apache.calcite.runtime.GeoFunctions.ST_MakePoint(java.math.BigDecimal,
java.math.BigDecimal)"
at org.codehaus.janino.UnitCompiler.compileError(UnitCompiler.java:12211)
at
org.codehaus.janino.UnitCompiler.findMostSpecificIInvocable(UnitCompiler.java:9263)
at org.codehaus.janino.UnitCompiler.findIMethod(UnitCompiler.java:9123)
at org.codehaus.janino.UnitCompiler.findIMethod(UnitCompiler.java:9025)
at org.codehaus.janino.UnitCompiler.compileGet2(UnitCompiler.java:5062)
at org.codehaus.janino.UnitCompiler.access$9100(UnitCompiler.java:215){code}
> Convert function operand type to match implementation if necessary in runtime
> -
>
> Key: CALCITE-3563
> URL: https://issues.apache.org/jira/browse/CALCITE-3563
> Project: Calcite
> Issue Type: Sub-task
> Components: core
>Reporter: Feng Zhu
>Assignee: Feng Zhu
>Priority: Major
>
> Sub-task targets on following issue.
>
> (1)Validation phase allows a wide range of operand types, but the runtime
> implementation does not cover all cases.
> For example, _*SqlFunction(MOD)*_ adopts
> _*OperandTypes.EXACT_NUMERIC_EXACT_NUMERIC*_.
> {code:java}
> @Test public void test0() {
> final String sql = "SELECT mod(12.5, cast(1 as bigint))";
> CalciteAssert.that()
> .query(sql)
> .returns("EXPR$0=0.5\n");
> }{code}
> We will get:
> {code:java}
> java.lang.RuntimeException: while resolving method 'mod[class
> java.math.BigDecimal, long]' in class class
> org.apache.calcite.runtime.SqlFunctions
> at org.apache.calcite.linq4j.tree.Types.lookupMethod(Types.java:323)
> at org.apache.calcite.linq4j.tree.Expressions.call(Expressions.java:445)
> at
>
[jira] [Updated] (CALCITE-3562) Unify function's operands type check logic in validation and behavior in runtime
[
https://issues.apache.org/jira/browse/CALCITE-3562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Feng Zhu updated CALCITE-3562:
--
Description:
Current now, there are many issues caused by inconsistency between validator
and runtime phase. To summarize:
(1)Validation phase allows a wide range of operand types, but the runtime
implementation does not cover all cases.
For example, _*SqlFunction(MOD)*_ adopts
_*OperandTypes.EXACT_NUMERIC_EXACT_NUMERIC*_.
{code:java}
@Test public void test0() {
final String sql = "SELECT mod(12.5, cast(1 as bigint))";
CalciteAssert.that()
.query(sql)
.returns("EXPR$0=0.5\n");
}{code}
We will get:
{code:java}
java.lang.RuntimeException: while resolving method 'mod[class
java.math.BigDecimal, long]' in class class
org.apache.calcite.runtime.SqlFunctions
at org.apache.calcite.linq4j.tree.Types.lookupMethod(Types.java:323)
at org.apache.calcite.linq4j.tree.Expressions.call(Expressions.java:445)
at
org.apache.calcite.adapter.enumerable.RexImpTable$MethodNameImplementor.implement(RexImpTable.java:2253)
at
org.apache.calcite.adapter.enumerable.RexImpTable.implementCall(RexImpTable.java:1195){code}
(2)Type is assignable conceptually, but in the runtime phase, explicite cast is
still required.
For example, according to _*SqlTypeAssignmentRules*_, *_ST_MakePoint(Decimal,
Decimal)_* also accepts operands with (_Integer_, _Decimal_) types, because
Decimal is assignable from Integer.
{code:java}
@Test public void test1() {
final String sql = "SELECT ST_MakePoint(1, 2.1)";
CalciteAssert.that()
.with(CalciteAssert.Config.GEO)
.query(sql)
.returns("EXPR$0={\"x\":1,\"y\":2.1}\n");
}
{code}
We will get:
{code:java}
org.codehaus.commons.compiler.CompileException: Line 22, Column 124: No
applicable constructor/method found for actual parameters "int,
java.math.BigDecimal"; candidates are: "public static
org.apache.calcite.runtime.GeoFunctions$Geom
org.apache.calcite.runtime.GeoFunctions.ST_MakePoint(java.math.BigDecimal,
java.math.BigDecimal, java.math.BigDecimal)", "public static
org.apache.calcite.runtime.GeoFunctions$Geom
org.apache.calcite.runtime.GeoFunctions.ST_MakePoint(java.math.BigDecimal,
java.math.BigDecimal)"
at org.codehaus.janino.UnitCompiler.compileError(UnitCompiler.java:12211)
at
org.codehaus.janino.UnitCompiler.findMostSpecificIInvocable(UnitCompiler.java:9263)
at org.codehaus.janino.UnitCompiler.findIMethod(UnitCompiler.java:9123)
at org.codehaus.janino.UnitCompiler.findIMethod(UnitCompiler.java:9025)
at org.codehaus.janino.UnitCompiler.compileGet2(UnitCompiler.java:5062)
at org.codehaus.janino.UnitCompiler.access$9100(UnitCompiler.java:215){code}
(3)For some functions, it is too late to fail the query in runtime phase.
For example: _*RAND_INTEGER*_ adopts _*OperandTypes.or(OperandTypes.NUMERIC,
OperandTypes.NUMERIC_NUMERIC)*_
{code:java}
@Test public void test2() {
final String sql = "SELECT rand_integer(1.1, 2)";
CalciteAssert.that()
.query(sql)
.planContains("xyxyx")
.returns("EXPR$0={\"x\":1,\"y\":2.1}\n");
}{code}
We will get:
{code:java}
org.codehaus.commons.compiler.CompileException: Line 22, Column 100: No
applicable constructor/method found for actual parameters
"java.math.BigDecimal, int"; candidates are: "public int
org.apache.calcite.runtime.RandomFunction.randIntegerSeed(int, int)"
at org.codehaus.janino.UnitCompiler.compileError(UnitCompiler.java:12211)
at
org.codehaus.janino.UnitCompiler.findMostSpecificIInvocable(UnitCompiler.java:9263)
at org.codehaus.janino.UnitCompiler.findIMethod(UnitCompiler.java:9123){code}
*How to fix?*
>From my personal view, for case (1) and (2), we need to fix it in runtime
>layer with a "try-best" mechanism to convert operand type to match the
>implementation.
The difference between them: case(1) is builtin function, we cannot get exact
argument types, while case(2) is udf.
We need to handle them separately.
For case(3), it seems more suitable to fix in Validation phase.
was:
Current now, there are many issues caused by inconsistency between validator
and runtime phase. To summarize:
(1)Validation phase allows a wide range of operand types, but the runtime
implementation does not cover all cases.
For example, _*SqlFunction(MOD)*_ adopts
_*OperandTypes.EXACT_NUMERIC_EXACT_NUMERIC*_.
{code:java}
@Test public void test0() {
final String sql = "SELECT mod(12.5, cast(1 as bigint))";
CalciteAssert.that()
.query(sql)
.returns("EXPR$0=0.5\n");
}{code}
We will get:
{code:java}
java.lang.RuntimeException: while resolving method 'mod[class
java.math.BigDecimal, long]' in class class
org.apache.calcite.runtime.SqlFunctions
at org.apache.calcite.linq4j.tree.Types.lookupMethod(Types.java:323)
at org.apache.calcite.linq4j.tree.Expressions.call(Expressions.java:445)
at
