[jira] [Created] (CALCITE-3175) Serialize to json of trim function cause exception
Wang Yanlin created CALCITE-3175: Summary: Serialize to json of trim function cause exception Key: CALCITE-3175 URL: https://issues.apache.org/jira/browse/CALCITE-3175 Project: Calcite Issue Type: Bug Components: core Reporter: Wang Yanlin Serialize the RexCall of *trim* function cause *java.lang.AssertionError* exception. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-3177) Deserialize from json of + operator cause exception
Wang Yanlin created CALCITE-3177: Summary: Deserialize from json of + operator cause exception Key: CALCITE-3177 URL: https://issues.apache.org/jira/browse/CALCITE-3177 Project: Calcite Issue Type: Bug Reporter: Wang Yanlin Attachments: error_info.jpg For a simple sql string "select SAL + 10 FROM SALES.EMP", parse it to RelNode, serialize it to json string works well, but deserialize from the json string cause exception. The error stack is in the error_info.jpg picture. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-3177) Deserialize from json of + operator cause exception
[ https://issues.apache.org/jira/browse/CALCITE-3177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16900027#comment-16900027 ] Wang Yanlin commented on CALCITE-3177: -- OK. I will pay attention to that in future. And thanks for reviewing. > Deserialize from json of + operator cause exception > --- > > Key: CALCITE-3177 > URL: https://issues.apache.org/jira/browse/CALCITE-3177 > Project: Calcite > Issue Type: Bug >Reporter: Wang Yanlin >Priority: Major > Labels: pull-request-available > Attachments: error_info.jpg > > Time Spent: 1h > Remaining Estimate: 0h > > For a simple sql string "select SAL + 10 FROM SALES.EMP", parse it to > RelNode, serialize it to json string works well, but deserialize from the > json string cause exception. The error stack is in the error_info.jpg picture. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (CALCITE-3246) NullPointerException while deserializing of udf.
Wang Yanlin created CALCITE-3246:
Summary: NullPointerException while deserializing of udf.
Key: CALCITE-3246
URL: https://issues.apache.org/jira/browse/CALCITE-3246
Project: Calcite
Issue Type: Bug
Components: core
Reporter: Wang Yanlin
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 sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (CALCITE-3254) AssertionError while deserializing of interval type.
Wang Yanlin created CALCITE-3254:
Summary: AssertionError while deserializing of interval type.
Key: CALCITE-3254
URL: https://issues.apache.org/jira/browse/CALCITE-3254
Project: Calcite
Issue Type: Bug
Reporter: Wang Yanlin
When deserializing of logical rel haveing interval type, AssertionError occurs.
The exception stacktrace as follow:
{code:java}
java.lang.RuntimeException: java.lang.RuntimeException:
java.lang.AssertionError: use createSqlIntervalType() instead
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.testInterval(RelWriterTest.java:639)
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.RuntimeException: java.lang.AssertionError: use
createSqlIntervalType() instead
at
org.apache.calcite.rel.externalize.RelJsonReader.readRel(RelJsonReader.java:271)
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$testInterval$8(RelWriterTest.java:644)
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
Caused by: java.lang.AssertionError: use createSqlIntervalType() instead
at
org.apache.calcite.sql.type.SqlTypeFactoryImpl.assertBasic(SqlTypeFactoryImpl.java:222)
at
org.apache.calcite.sql.type.SqlTypeFactoryImpl.createSqlType(SqlTypeFactoryImpl.java:75)
at org.apache.calcite.rel.externalize.RelJson.toType(RelJson.java:222)
at org.apache.calcite.rel.externalize.RelJson.toRex(RelJson.java:516)
at
org.apache.calcite.rel.externalize.RelJson.toRexList(RelJson.java:607)
at org.apache.calcite.rel.externalize.RelJson.toRex(RelJson.java:447)
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)
... 31 more
{code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (CALCITE-3246) NullPointerException while deserializing of udf.
[
https://issues.apache.org/jira/browse/CALCITE-3246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16909016#comment-16909016
]
Wang Yanlin commented on CALCITE-3246:
--
The class name is put into the json string in [to json
function|https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/rel/externalize/RelJson.java#L366].
Any more details on how to check the security implications?
> NullPointerException while deserializing of 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.21.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
[jira] [Commented] (CALCITE-3254) AssertionError while deserializing of interval type.
[
https://issues.apache.org/jira/browse/CALCITE-3254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16909481#comment-16909481
]
Wang Yanlin commented on CALCITE-3254:
--
OK, I update the descritpion in pr. Thanks for reviewing.
> AssertionError while deserializing of interval type.
>
>
> Key: CALCITE-3254
> URL: https://issues.apache.org/jira/browse/CALCITE-3254
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When deserializing of logical rel haveing interval type, AssertionError
> occurs.
> The exception stacktrace as follow:
> {code:java}
> java.lang.RuntimeException: java.lang.RuntimeException:
> java.lang.AssertionError: use createSqlIntervalType() instead
> 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.testInterval(RelWriterTest.java:639)
> 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.RuntimeException: java.lang.AssertionError: use
> createSqlIntervalType() instead
> at
> org.apache.calcite.rel.externalize.RelJsonReader.readRel(RelJsonReader.java:271)
> 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$testInterval$8(RelWriterTest.java:644)
> 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
> Caused by: java.lang.AssertionError: use createSqlIntervalType() instead
> at
> org.apache.calcite.sql.type.SqlTypeFactoryImpl.assertBasic(SqlTypeFactoryImpl.java:222)
> at
> org.apache.calcite.sql.type.SqlTypeFactoryImpl.createSqlType(SqlTypeFactoryImpl.java:75)
> at org.apache.calcite.rel.externalize.RelJson.toType(RelJson.java:222)
> at org.apache.calcite.rel.externalize.RelJson.toRex(RelJson.java:516)
> at
> org.apache.calcite.rel.externalize.RelJson.toRexList(RelJson.java:607)
> at org.apache.calcite.rel.externalize.RelJson.toRex(RelJson.java:447)
> 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.NativeConstructor
[jira] [Created] (CALCITE-3259) Align 'Property' in the serialized xml string of RelXmlWriter.
Wang Yanlin created CALCITE-3259:
Summary: Align 'Property' in the serialized xml string of
RelXmlWriter.
Key: CALCITE-3259
URL: https://issues.apache.org/jira/browse/CALCITE-3259
Project: Calcite
Issue Type: Improvement
Reporter: Wang Yanlin
In the serialized xml string of RelXmlWriter, the 'Property' label is aligned.
For the sql below
{noformat}
select 1 + 2, 3 from (values (true))
{noformat}
the serialized xml string is like this:
{noformat}
+(1, 2)
3
[{ true }]
{noformat}
It's better to make 'Property' aligned.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (CALCITE-3260) Add support of evaluate with default Evaluator.
Wang Yanlin created CALCITE-3260: Summary: Add support of evaluate with default Evaluator. Key: CALCITE-3260 URL: https://issues.apache.org/jira/browse/CALCITE-3260 Project: Calcite Issue Type: New Feature Reporter: Wang Yanlin Currently, the public method *evaluate* of AbstractNode need a Evaluator object as parameter, but Evaluator class has default access control. This limit the access of *evaluate* method. So may be we can add an overload *evaluate* method with default Evaluator, thus, allow the evaluate Expression directly. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (CALCITE-3260) Add support of evaluate method with default Evaluator.
[ https://issues.apache.org/jira/browse/CALCITE-3260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wang Yanlin updated CALCITE-3260: - Summary: Add support of evaluate method with default Evaluator. (was: Add support of evaluate with default Evaluator.) > Add support of evaluate method with default Evaluator. > -- > > Key: CALCITE-3260 > URL: https://issues.apache.org/jira/browse/CALCITE-3260 > Project: Calcite > Issue Type: New Feature >Reporter: Wang Yanlin >Priority: Minor > > Currently, the public method *evaluate* of AbstractNode need a Evaluator > object as parameter, but Evaluator class has default access control. This > limit the access of *evaluate* method. So may be we can add an overload > *evaluate* method with default Evaluator, thus, allow the evaluate Expression > directly. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (CALCITE-3260) Add support of evaluate method with default Evaluator.
[ https://issues.apache.org/jira/browse/CALCITE-3260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wang Yanlin updated CALCITE-3260: - Description: Currently, the public method *evaluate* of AbstractNode need a Evaluator object as parameter, but Evaluator class has default access control. This limit the access of *evaluate* method. So may be we can add an overload *evaluate* method with default Evaluator, thus, allow to evaluate Expression directly. (was: Currently, the public method *evaluate* of AbstractNode need a Evaluator object as parameter, but Evaluator class has default access control. This limit the access of *evaluate* method. So may be we can add an overload *evaluate* method with default Evaluator, thus, allow the evaluate Expression directly.) > Add support of evaluate method with default Evaluator. > -- > > Key: CALCITE-3260 > URL: https://issues.apache.org/jira/browse/CALCITE-3260 > Project: Calcite > Issue Type: New Feature >Reporter: Wang Yanlin >Priority: Minor > > Currently, the public method *evaluate* of AbstractNode need a Evaluator > object as parameter, but Evaluator class has default access control. This > limit the access of *evaluate* method. So may be we can add an overload > *evaluate* method with default Evaluator, thus, allow to evaluate Expression > directly. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (CALCITE-3260) Add support of evaluate method with default Evaluator.
[ https://issues.apache.org/jira/browse/CALCITE-3260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16911351#comment-16911351 ] Wang Yanlin commented on CALCITE-3260: -- Well, then can we make class *Evaluator* public, so that, we can also be able to evaluate Expression directly. > Add support of evaluate method with default Evaluator. > -- > > Key: CALCITE-3260 > URL: https://issues.apache.org/jira/browse/CALCITE-3260 > Project: Calcite > Issue Type: New Feature >Reporter: Wang Yanlin >Priority: Minor > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > Currently, the public method *evaluate* of AbstractNode need a Evaluator > object as parameter, but Evaluator class has default access control. This > limit the access of *evaluate* method. So may be we can add an overload > *evaluate* method with default Evaluator, thus, allow to evaluate Expression > directly. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Comment Edited] (CALCITE-3260) Add support of evaluate method with default Evaluator.
[ https://issues.apache.org/jira/browse/CALCITE-3260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16911351#comment-16911351 ] Wang Yanlin edited comment on CALCITE-3260 at 8/20/19 1:31 PM: --- Well, then can we make class *Evaluator* public, so that, we can also be able to evaluate Expression directly. [~julianhyde] was (Author: yanlin-lynn): Well, then can we make class *Evaluator* public, so that, we can also be able to evaluate Expression directly. > Add support of evaluate method with default Evaluator. > -- > > Key: CALCITE-3260 > URL: https://issues.apache.org/jira/browse/CALCITE-3260 > Project: Calcite > Issue Type: New Feature >Reporter: Wang Yanlin >Priority: Minor > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > Currently, the public method *evaluate* of AbstractNode need a Evaluator > object as parameter, but Evaluator class has default access control. This > limit the access of *evaluate* method. So may be we can add an overload > *evaluate* method with default Evaluator, thus, allow to evaluate Expression > directly. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (CALCITE-3260) Add support of evaluate method with default Evaluator.
[ https://issues.apache.org/jira/browse/CALCITE-3260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16912194#comment-16912194 ] Wang Yanlin commented on CALCITE-3260: -- Yes, that's better. I will update the PR. > Add support of evaluate method with default Evaluator. > -- > > Key: CALCITE-3260 > URL: https://issues.apache.org/jira/browse/CALCITE-3260 > Project: Calcite > Issue Type: New Feature >Reporter: Wang Yanlin >Priority: Minor > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > Currently, the public method *evaluate* of AbstractNode need a Evaluator > object as parameter, but Evaluator class has default access control. This > limit the access of *evaluate* method. So may be we can add an overload > *evaluate* method with default Evaluator, thus, allow to evaluate Expression > directly. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[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&focusedCommentId=16912199#comment-16912199
]
Wang Yanlin commented on CALCITE-3246:
--
OK. And, any suggestion for update?
> 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.21.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 w
[jira] [Created] (CALCITE-3278) Simplify the use to translate RexNode to Expression for evaluating
Wang Yanlin created CALCITE-3278:
Summary: Simplify the use to translate RexNode to Expression for
evaluating
Key: CALCITE-3278
URL: https://issues.apache.org/jira/browse/CALCITE-3278
Project: Calcite
Issue Type: Improvement
Components: core
Reporter: Wang Yanlin
The method *forAggregation* of *RexToLixTranslator* is designed to work for
translating aggregate functions, with some parameters that we actually do not
need, if we just want to translate a single RexNode.
We lack a more common sense function to get an instance of RexToLixTranslator.
And, the translated expression is a *ParameterExpression*, not fit for
evaluating. When evaluating, we get an exception like this
{code:java}
java.lang.RuntimeException: parameter v not on stack
at org.apache.calcite.linq4j.tree.Evaluator.peek(Evaluator.java:51)
at
org.apache.calcite.linq4j.tree.ParameterExpression.evaluate(ParameterExpression.java:55)
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.adapter.enumerable.RexToLixTranslatorTest.testRawTranslateRexNode(RexToLixTranslatorTest.java:57)
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}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Comment Edited] (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&focusedCommentId=16912199#comment-16912199
]
Wang Yanlin edited comment on CALCITE-3246 at 8/21/19 2:39 PM:
---
OK. And, any suggestion for updating the PR? [~julianhyde]
was (Author: yanlin-lynn):
OK. And, any suggestion for update?
> 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.21.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.ja
[jira] [Commented] (CALCITE-3278) Simplify the use to translate RexNode to Expression for evaluating
[
https://issues.apache.org/jira/browse/CALCITE-3278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16912870#comment-16912870
]
Wang Yanlin commented on CALCITE-3278:
--
[~rubenql], thanks for reminding.
This one is a small improvement to simplify the use for translating, add new
function.
I checked the CALCITE-3224, it is a refactor for the implementation.
Currently, it will not interfere or supersede this one. But there may exist
some conflict in the code.
I will close this one if CALCITE-3224 changes and supersedes this one.
> Simplify the use to translate RexNode to Expression for evaluating
> --
>
> Key: CALCITE-3278
> URL: https://issues.apache.org/jira/browse/CALCITE-3278
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Wang Yanlin
>Priority: Minor
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The method *forAggregation* of *RexToLixTranslator* is designed to work for
> translating aggregate functions, with some parameters that we actually do not
> need, if we just want to translate a single RexNode.
> We lack a more common sense function to get an instance of
> RexToLixTranslator.
> And, the translated expression is a *ParameterExpression*, not fit for
> evaluating. When evaluating, we get an exception like this
> {code:java}
> java.lang.RuntimeException: parameter v not on stack
> at org.apache.calcite.linq4j.tree.Evaluator.peek(Evaluator.java:51)
> at
> org.apache.calcite.linq4j.tree.ParameterExpression.evaluate(ParameterExpression.java:55)
> 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.adapter.enumerable.RexToLixTranslatorTest.testRawTranslateRexNode(RexToLixTranslatorTest.java:57)
> 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}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Created] (CALCITE-3281) Support mixed Primitive types for BinaryExpression evaluate method.
Wang Yanlin created CALCITE-3281:
Summary: 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
Reporter: Wang Yanlin
{code:java}
// code placeholder
{code}
Currently, the value of [expression0 |http://www.baidu.com/] and [expression1|]
should be
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[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
]
Wang Yanlin updated CALCITE-3281:
-
Description:
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.
was:
{code:java}
// code placeholder
{code}
Currently, the value of [expression0 |http://www.baidu.com/] and [expression1|]
should be
> 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
>Reporter: Wang Yanlin
>Priority: Major
>
> 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.Frame
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=16913298#comment-16913298
]
Wang Yanlin commented on CALCITE-3281:
--
OK. I will update the PR.
> 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
>Reporter: Wang Yanlin
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> 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.2#803003)
[jira] [Created] (CALCITE-3295) Aggregate call name lost in serialized json string.
Wang Yanlin created CALCITE-3295:
Summary: Aggregate call name lost in serialized json string.
Key: CALCITE-3295
URL: https://issues.apache.org/jira/browse/CALCITE-3295
Project: Calcite
Issue Type: Bug
Reporter: Wang Yanlin
When serialize a relnode to json string, the name of aggregate call was lost.
For a sql string like this
{code:java}
SELECT max(SAL) as max_sal from EMP group by JOB;
{code}
The serialized json string is like this
{code:java}
{
"rels": [
{
"id": "0",
"relOp": "LogicalTableScan",
"table": [
"scott",
"EMP"
],
"inputs": []
},
{
"id": "1",
"relOp": "LogicalProject",
"fields": [
"JOB",
"SAL"
],
"exprs": [
{
"input": 2,
"name": "$2"
},
{
"input": 5,
"name": "$5"
}
]
},
{
"id": "2",
"relOp": "LogicalAggregate",
"group": [
0
],
"aggs": [
{
"agg": {
"name": "MAX",
"kind": "MAX",
"syntax": "FUNCTION"
},
"type": {
"type": "DECIMAL",
"nullable": true,
"precision": 7,
"scale": 2
},
"distinct": false,
"operands": [
1
],
}
]
},
{
"id": "3",
"relOp": "LogicalProject",
"fields": [
"max_sal"
],
"exprs": [
{
"input": 1,
"name": "$1"
}
]
}
]
}
{code}
Lost the name of max call.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Created] (CALCITE-3306) Add REGEXP_SPLIT_TO_ARRAY function
Wang Yanlin created CALCITE-3306: Summary: Add REGEXP_SPLIT_TO_ARRAY function Key: CALCITE-3306 URL: https://issues.apache.org/jira/browse/CALCITE-3306 Project: Calcite Issue Type: New Feature Reporter: Wang Yanlin In work, I found there is no coresponding *split* function in calcite like the * regexp_split_to_array* in [PostgreSQL|https://www.postgresql.org/docs/9.1/functions-matching.html]. Although we can solve this by creating a udf based on calcite, but a built in function might be better. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (CALCITE-3306) Add REGEXP_SPLIT_TO_ARRAY function
[ https://issues.apache.org/jira/browse/CALCITE-3306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wang Yanlin updated CALCITE-3306: - Description: In work, I found there is no coresponding *split* function in calcite like the *regexp_split_to_array* in [PostgreSQL|https://www.postgresql.org/docs/9.1/functions-matching.html]. Although we can solve this by creating a udf based on calcite, but a built in function might be better. was: In work, I found there is no coresponding *split* function in calcite like the * regexp_split_to_array* in [PostgreSQL|https://www.postgresql.org/docs/9.1/functions-matching.html]. Although we can solve this by creating a udf based on calcite, but a built in function might be better. > Add REGEXP_SPLIT_TO_ARRAY function > -- > > Key: CALCITE-3306 > URL: https://issues.apache.org/jira/browse/CALCITE-3306 > Project: Calcite > Issue Type: New Feature >Reporter: Wang Yanlin >Priority: Major > > In work, I found there is no coresponding *split* function in calcite like > the *regexp_split_to_array* in > [PostgreSQL|https://www.postgresql.org/docs/9.1/functions-matching.html]. > Although we can solve this by creating a udf based on calcite, but a built in > function might be better. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (CALCITE-3306) Add REGEXP_SPLIT_TO_ARRAY function
[ https://issues.apache.org/jira/browse/CALCITE-3306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wang Yanlin updated CALCITE-3306: - Description: In work, I need to split a string into array. But I found there is no coresponding *split* function in calcite like the *regexp_split_to_array* in [PostgreSQL|https://www.postgresql.org/docs/9.1/functions-matching.html]. Although we can solve this by creating a udf based on calcite, but a built in function might be better. was: In work, I found there is no coresponding *split* function in calcite like the *regexp_split_to_array* in [PostgreSQL|https://www.postgresql.org/docs/9.1/functions-matching.html]. Although we can solve this by creating a udf based on calcite, but a built in function might be better. > Add REGEXP_SPLIT_TO_ARRAY function > -- > > Key: CALCITE-3306 > URL: https://issues.apache.org/jira/browse/CALCITE-3306 > Project: Calcite > Issue Type: New Feature >Reporter: Wang Yanlin >Priority: Major > > In work, I need to split a string into array. But I found there is no > coresponding *split* function in calcite like the *regexp_split_to_array* in > [PostgreSQL|https://www.postgresql.org/docs/9.1/functions-matching.html]. > Although we can solve this by creating a udf based on calcite, but a built in > function might be better. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (CALCITE-3306) Add REGEXP_SPLIT_TO_ARRAY function
[ https://issues.apache.org/jira/browse/CALCITE-3306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wang Yanlin updated CALCITE-3306: - Description: In work, I need to split a string into array. But I found there is no coresponding *split* function in calcite like the *regexp_split_to_array* in [PostgreSQL|https://www.postgresql.org/docs/9.1/functions-matching.html]. Although we can solve this by creating a udf based on calcite, but a built in function might be better, in case some others may have the same need. was: In work, I need to split a string into array. But I found there is no coresponding *split* function in calcite like the *regexp_split_to_array* in [PostgreSQL|https://www.postgresql.org/docs/9.1/functions-matching.html]. Although we can solve this by creating a udf based on calcite, but a built in function might be better. > Add REGEXP_SPLIT_TO_ARRAY function > -- > > Key: CALCITE-3306 > URL: https://issues.apache.org/jira/browse/CALCITE-3306 > Project: Calcite > Issue Type: New Feature >Reporter: Wang Yanlin >Priority: Major > > In work, I need to split a string into array. But I found there is no > coresponding *split* function in calcite like the *regexp_split_to_array* in > [PostgreSQL|https://www.postgresql.org/docs/9.1/functions-matching.html]. > Although we can solve this by creating a udf based on calcite, but a built in > function might be better, in case some others may have the same need. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (CALCITE-3290) evaluate in AbstractNode
[ https://issues.apache.org/jira/browse/CALCITE-3290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16918564#comment-16918564 ] Wang Yanlin commented on CALCITE-3290: -- Already implemented, please refer to [https://issues.apache.org/jira/projects/CALCITE/issues/CALCITE-3260] > evaluate in AbstractNode > > > Key: CALCITE-3290 > URL: https://issues.apache.org/jira/browse/CALCITE-3290 > Project: Calcite > Issue Type: Improvement >Reporter: xzh_dz >Priority: Critical > Labels: pull-request-available > Time Spent: 0.5h > Remaining Estimate: 0h > > we could implement the expressions evaluate in AbstractNode directly. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Comment Edited] (CALCITE-3290) evaluate in AbstractNode
[ https://issues.apache.org/jira/browse/CALCITE-3290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16918564#comment-16918564 ] Wang Yanlin edited comment on CALCITE-3290 at 8/29/19 12:34 PM: Already implemented, please refer to https://issues.apache.org/jira/browse/CALCITE-3260 was (Author: yanlin-lynn): Already implemented, please refer to [https://issues.apache.org/jira/projects/CALCITE/issues/CALCITE-3260] > evaluate in AbstractNode > > > Key: CALCITE-3290 > URL: https://issues.apache.org/jira/browse/CALCITE-3290 > Project: Calcite > Issue Type: Improvement >Reporter: xzh_dz >Priority: Critical > Labels: pull-request-available > Time Spent: 0.5h > Remaining Estimate: 0h > > we could implement the expressions evaluate in AbstractNode directly. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (CALCITE-3306) Add REGEXP_SPLIT_TO_ARRAY function
[ https://issues.apache.org/jira/browse/CALCITE-3306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16919285#comment-16919285 ] Wang Yanlin commented on CALCITE-3306: -- OK, I'll update the PR. > Add REGEXP_SPLIT_TO_ARRAY function > -- > > Key: CALCITE-3306 > URL: https://issues.apache.org/jira/browse/CALCITE-3306 > Project: Calcite > Issue Type: New Feature >Reporter: Wang Yanlin >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > In work, I need to split a string into array. But I found there is no > coresponding *split* function in calcite like the *regexp_split_to_array* in > [PostgreSQL|https://www.postgresql.org/docs/9.1/functions-matching.html]. > Although we can solve this by creating a udf based on calcite, but a built in > function might be better, in case some others may have the same need. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (CALCITE-3313) AssertionError for an invalid type when using REGEXP_REPLACE
Wang Yanlin created CALCITE-3313:
Summary: AssertionError for an invalid type when using
REGEXP_REPLACE
Key: CALCITE-3313
URL: https://issues.apache.org/jira/browse/CALCITE-3313
Project: Calcite
Issue Type: Bug
Reporter: Wang Yanlin
When using REGEXP_REPLACE function with an invalid type parameter, like this
{code:sql}
select regexp_replace(12, 'b', 'X', 1, 3, 'i')
{code}
we got
{code:java}
java.lang.AssertionError: If you see this, assign operandTypeChecker a value or
override this function
at
org.apache.calcite.sql.SqlOperator.getAllowedSignatures(SqlOperator.java:730)
at
org.apache.calcite.sql.SqlOperator.getAllowedSignatures(SqlOperator.java:721)
at
org.apache.calcite.sql.SqlCallBinding.newValidationSignatureError(SqlCallBinding.java:283)
at
org.apache.calcite.sql.type.FamilyOperandTypeChecker.checkSingleOperandType(FamilyOperandTypeChecker.java:96)
at
org.apache.calcite.sql.fun.SqlRegexpReplaceFunction.checkOperandTypes(SqlRegexpReplaceFunction.java:56)
at
org.apache.calcite.sql.SqlOperator.validateOperands(SqlOperator.java:432)
at org.apache.calcite.sql.SqlFunction.deriveType(SqlFunction.java:298)
at org.apache.calcite.sql.SqlFunction.deriveType(SqlFunction.java:216)
at
org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5626)
at
org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5613)
at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:139)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.deriveTypeImpl(SqlValidatorImpl.java:1688)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.deriveType(SqlValidatorImpl.java:1673)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.expandSelectItem(SqlValidatorImpl.java:476)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelectList(SqlValidatorImpl.java:4104)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3392)
at
org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:60)
at
org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:1005)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:965)
at org.apache.calcite.sql.SqlSelect.validate(SqlSelect.java:216)
{code}
Better to give a more detailed message of the allowed signatures.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (CALCITE-3313) AssertionError for using an invalid type parameter in REGEXP_REPLACE
[
https://issues.apache.org/jira/browse/CALCITE-3313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin updated CALCITE-3313:
-
Summary: AssertionError for using an invalid type parameter in
REGEXP_REPLACE (was: AssertionError for an invalid type when using
REGEXP_REPLACE)
> AssertionError for using an invalid type parameter in REGEXP_REPLACE
>
>
> Key: CALCITE-3313
> URL: https://issues.apache.org/jira/browse/CALCITE-3313
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Priority: Minor
>
> When using REGEXP_REPLACE function with an invalid type parameter, like this
> {code:sql}
> select regexp_replace(12, 'b', 'X', 1, 3, 'i')
> {code}
> we got
> {code:java}
> java.lang.AssertionError: If you see this, assign operandTypeChecker a value
> or override this function
> at
> org.apache.calcite.sql.SqlOperator.getAllowedSignatures(SqlOperator.java:730)
> at
> org.apache.calcite.sql.SqlOperator.getAllowedSignatures(SqlOperator.java:721)
> at
> org.apache.calcite.sql.SqlCallBinding.newValidationSignatureError(SqlCallBinding.java:283)
> at
> org.apache.calcite.sql.type.FamilyOperandTypeChecker.checkSingleOperandType(FamilyOperandTypeChecker.java:96)
> at
> org.apache.calcite.sql.fun.SqlRegexpReplaceFunction.checkOperandTypes(SqlRegexpReplaceFunction.java:56)
> at
> org.apache.calcite.sql.SqlOperator.validateOperands(SqlOperator.java:432)
> at org.apache.calcite.sql.SqlFunction.deriveType(SqlFunction.java:298)
> at org.apache.calcite.sql.SqlFunction.deriveType(SqlFunction.java:216)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5626)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5613)
> at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:139)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.deriveTypeImpl(SqlValidatorImpl.java:1688)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.deriveType(SqlValidatorImpl.java:1673)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.expandSelectItem(SqlValidatorImpl.java:476)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelectList(SqlValidatorImpl.java:4104)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3392)
> at
> org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:60)
> at
> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:1005)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:965)
> at org.apache.calcite.sql.SqlSelect.validate(SqlSelect.java:216)
> {code}
> Better to give a more detailed message of the allowed signatures.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Created] (CALCITE-3316) Exception while deserializing LogicalCorrelate from json string
Wang Yanlin created CALCITE-3316:
Summary: Exception while deserializing LogicalCorrelate from json
string
Key: CALCITE-3316
URL: https://issues.apache.org/jira/browse/CALCITE-3316
Project: Calcite
Issue Type: Bug
Components: core
Reporter: Wang Yanlin
When deserializing LogicalCorrelate, we get
{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.testCorrelateQuery(RelWriterTest.java:686)
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
org.apache.calcite.rel.logical.LogicalCorrelate.(LogicalCorrelate.java:83)
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$testCorrelateQuery$9(RelWriterTest.java:691)
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}
And, after fix the NPE, get
{code:java}
java.lang.RuntimeException: java.lang.ClassCastException: java.lang.String
cannot be cast to java.util.List
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.testCorrelateQuery(RelWriterTest.java:686)
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
[jira] [Created] (CALCITE-3317) Add public constructor for creating LogicalCalc with RelInput type parameter
Wang Yanlin created CALCITE-3317:
Summary: Add public constructor for creating LogicalCalc with
RelInput type parameter
Key: CALCITE-3317
URL: https://issues.apache.org/jira/browse/CALCITE-3317
Project: Calcite
Issue Type: Bug
Reporter: Wang Yanlin
When trying to deserializing a RelNode contains a LogicalCalc node in the
tree, got
{code:java}
java.lang.RuntimeException: java.lang.RuntimeException: class does not have
required constructor, class org.apache.calcite.rel.logical.LogicalCalc(RelInput)
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.testCalc(RelWriterTest.java:688)
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.RuntimeException: class does not have required
constructor, class org.apache.calcite.rel.logical.LogicalCalc(RelInput)
at
org.apache.calcite.rel.externalize.RelJson.getConstructor(RelJson.java:114)
at
org.apache.calcite.rel.externalize.RelJsonReader.readRel(RelJsonReader.java:98)
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$testCalc$9(RelWriterTest.java:693)
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}
Need to add a public constructor for creating LogicalCalc with RelInput type
parameter, like this
{code:java}
public LogicalCalc(RelInput input)
{code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Created] (CALCITE-3319) AssertionError for ReduceDecimalsRule
Wang Yanlin created CALCITE-3319:
Summary: AssertionError for ReduceDecimalsRule
Key: CALCITE-3319
URL: https://issues.apache.org/jira/browse/CALCITE-3319
Project: Calcite
Issue Type: Bug
Reporter: Wang Yanlin
When trying to use *ReduceDecimalsRule*, I got
{code:java}
java.lang.AssertionError
at
org.apache.calcite.rel.rules.ReduceDecimalsRule$DecimalShuttle.visitCall(ReduceDecimalsRule.java:159)
at
org.apache.calcite.rel.rules.ReduceDecimalsRule$DecimalShuttle.visitCall(ReduceDecimalsRule.java:124)
at org.apache.calcite.rex.RexCall.accept(RexCall.java:191)
at
org.apache.calcite.rex.RexProgramBuilder.add(RexProgramBuilder.java:653)
at
org.apache.calcite.rex.RexProgramBuilder.create(RexProgramBuilder.java:601)
at
org.apache.calcite.rel.rules.ReduceDecimalsRule.onMatch(ReduceDecimalsRule.java:103)
at
org.apache.calcite.plan.AbstractRelOptPlanner.fireRule(AbstractRelOptPlanner.java:319)
at org.apache.calcite.plan.hep.HepPlanner.applyRule(HepPlanner.java:560)
at
org.apache.calcite.plan.hep.HepPlanner.applyRules(HepPlanner.java:419)
at
org.apache.calcite.plan.hep.HepPlanner.executeInstruction(HepPlanner.java:256)
at
org.apache.calcite.plan.hep.HepInstruction$RuleInstance.execute(HepInstruction.java:127)
at
org.apache.calcite.plan.hep.HepPlanner.executeProgram(HepPlanner.java:215)
at
org.apache.calcite.plan.hep.HepPlanner.findBestExp(HepPlanner.java:202)
{code}
I read the code, and found this.
{code:java}
List newOperands = apply(call.getOperands());
if (true) {
// FIXME: Operands are now immutable. Create a new call with
// new operands?
throw new AssertionError();
}
{code}
After remove this logic, the rel below
{code:java}
LogicalCalc(expr#0..7=[{inputs}], expr#8=[1.01E1:DOUBLE], expr#9=[15],
expr#10=[+($t8, $t9)], expr#11=[>($t5, $t10)], proj#0..7=[{exprs}],
$condition=[$t11])
LogicalTableScan(table=[[scott, EMP]])
{code}
can be translated into
{code:java}
LogicalCalc(expr#0..7=[{inputs}], expr#8=[Reinterpret($t5)],
expr#9=[CAST($t8):DOUBLE], expr#10=[1E2:DOUBLE], expr#11=[/INT($t9, $t10)],
expr#12=[1.01E1:DOUBLE], expr#13=[15], expr#14=[+($t12, $t13)],
expr#15=[>($t11, $t14)], proj#0..7=[{exprs}], $condition=[$t15])
LogicalTableScan(table=[[scott, EMP]])
{code}
So is this rule not ready for use now, or we should just remove this logic?
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (CALCITE-4022) Support unparse special syntax when operator is INSERT
[
https://issues.apache.org/jira/browse/CALCITE-4022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17164073#comment-17164073
]
Wang Yanlin commented on CALCITE-4022:
--
Fixed in
[https://github.com/apache/calcite/pull/2014/commits/a45f7b78e4d3891d36abfa9213c609f896601c36],
thanks [~xzh_dz] .
> Support unparse special syntax when operator is INSERT
> --
>
> Key: CALCITE-4022
> URL: https://issues.apache.org/jira/browse/CALCITE-4022
> Project: Calcite
> Issue Type: Wish
>Reporter: xzh_dz
>Priority: Major
> Labels: pull-request-available
> Attachments: image-2020-05-25-17-38-36-009.png
>
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> This exception can be reproduced as below:
> SqlParserTest:
> {code:java}
> @Test void test() throws Exception {
> final String sql = "insert into emps select * from emps";
> final SqlNode sqlNode = getSqlParser(sql).parseStmt();
> final SqlNode sqlNodeVisited = sqlNode.accept(new SqlShuttle() {
> @Override public SqlNode visit(SqlIdentifier identifier) {
> return new SqlIdentifier(identifier.names,
> identifier.getParserPosition());
> }
> });
> System.out.println(sqlNodeVisited.toString());
> }
> {code}
> !image-2020-05-25-17-38-36-009.png!
> Method threw 'java.lang.UnsupportedOperationException' exception. Cannot
> evaluate org.apache.calcite.sql.SqlBasicCall.toString()
> SqlInsert is a SqlSpecialOperator, when `toString` method is called, this
> problem is shown.We can see that `SqlSyntax#SPECIAL#unparse()` hasn't been
> implemented yet.
> exception :
> java.lang.UnsupportedOperationException: class
> org.apache.calcite.sql.SqlSyntax$6: SPECIAL
> at org.apache.calcite.util.Util.needToImplement(Util.java:967)
> at org.apache.calcite.sql.SqlSyntax$6.unparse(SqlSyntax.java:116)
> at org.apache.calcite.sql.SqlOperator.unparse(SqlOperator.java:333)
> at org.apache.calcite.sql.SqlDialect.unparseCall(SqlDialect.java:462)
> at org.apache.calcite.sql.SqlCall.unparse(SqlCall.java:104)
> at org.apache.calcite.sql.SqlNode.toSqlString(SqlNode.java:151)
> at org.apache.calcite.sql.SqlNode.toString(SqlNode.java:126)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CALCITE-4022) Support unparse special syntax when operator is INSERT
[
https://issues.apache.org/jira/browse/CALCITE-4022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin resolved CALCITE-4022.
--
Fix Version/s: 1.24.0
Resolution: Fixed
> Support unparse special syntax when operator is INSERT
> --
>
> Key: CALCITE-4022
> URL: https://issues.apache.org/jira/browse/CALCITE-4022
> Project: Calcite
> Issue Type: Wish
>Reporter: xzh_dz
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.24.0
>
> Attachments: image-2020-05-25-17-38-36-009.png
>
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> This exception can be reproduced as below:
> SqlParserTest:
> {code:java}
> @Test void test() throws Exception {
> final String sql = "insert into emps select * from emps";
> final SqlNode sqlNode = getSqlParser(sql).parseStmt();
> final SqlNode sqlNodeVisited = sqlNode.accept(new SqlShuttle() {
> @Override public SqlNode visit(SqlIdentifier identifier) {
> return new SqlIdentifier(identifier.names,
> identifier.getParserPosition());
> }
> });
> System.out.println(sqlNodeVisited.toString());
> }
> {code}
> !image-2020-05-25-17-38-36-009.png!
> Method threw 'java.lang.UnsupportedOperationException' exception. Cannot
> evaluate org.apache.calcite.sql.SqlBasicCall.toString()
> SqlInsert is a SqlSpecialOperator, when `toString` method is called, this
> problem is shown.We can see that `SqlSyntax#SPECIAL#unparse()` hasn't been
> implemented yet.
> exception :
> java.lang.UnsupportedOperationException: class
> org.apache.calcite.sql.SqlSyntax$6: SPECIAL
> at org.apache.calcite.util.Util.needToImplement(Util.java:967)
> at org.apache.calcite.sql.SqlSyntax$6.unparse(SqlSyntax.java:116)
> at org.apache.calcite.sql.SqlOperator.unparse(SqlOperator.java:333)
> at org.apache.calcite.sql.SqlDialect.unparseCall(SqlDialect.java:462)
> at org.apache.calcite.sql.SqlCall.unparse(SqlCall.java:104)
> at org.apache.calcite.sql.SqlNode.toSqlString(SqlNode.java:151)
> at org.apache.calcite.sql.SqlNode.toString(SqlNode.java:126)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (CALCITE-4177) Throw exception when deserialize SqlOperator fails, do not return null
[
https://issues.apache.org/jira/browse/CALCITE-4177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin reassigned CALCITE-4177:
Assignee: Wang Yanlin
> Throw exception when deserialize SqlOperator fails, do not return null
> --
>
> Key: CALCITE-4177
> URL: https://issues.apache.org/jira/browse/CALCITE-4177
> Project: Calcite
> Issue Type: Improvement
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Minor
>
> Currently, when deserialize a RexNode fails, calcite returns a null value,
> causing NPE in somewhere else. So we cannot get any information about the
> SqlOperator in the stacktrace. This makes hard to determine the reason when
> deserialize a very long json string.
> {noformat}
> Caused by: java.lang.NullPointerException
> at java.util.Objects.requireNonNull(Objects.java:203)
> at
> org.apache.calcite.rel.core.AggregateCall.(AggregateCall.java:98)
> at
> org.apache.calcite.rel.core.AggregateCall.create(AggregateCall.java:198)
> at
> org.apache.calcite.rel.externalize.RelJsonReader.toAggCall(RelJsonReader.java:289)
> at
> org.apache.calcite.rel.externalize.RelJsonReader.access$500(RelJsonReader.java:59)
> at
> org.apache.calcite.rel.externalize.RelJsonReader$2.getAggregateCalls(RelJsonReader.java:172)
> at org.apache.calcite.rel.core.Aggregate.(Aggregate.java:220)
> at
> org.apache.calcite.rel.logical.LogicalAggregate.(LogicalAggregate.java:105)
> 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:264)
> 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:894)
> at
> org.apache.calcite.tools.Frameworks.lambda$withPlanner$0(Frameworks.java:131)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.perform(CalcitePrepareImpl.java:914)
> at org.apache.calcite.tools.Frameworks.withPrepare(Frameworks.java:180)
> ... 67 more
> {noformat}
> Maybe it's better to throw exception instead of return null.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-4177) Throw exception when deserialize SqlOperator fails, do not return null
Wang Yanlin created CALCITE-4177:
Summary: Throw exception when deserialize SqlOperator fails, do
not return null
Key: CALCITE-4177
URL: https://issues.apache.org/jira/browse/CALCITE-4177
Project: Calcite
Issue Type: Improvement
Reporter: Wang Yanlin
Currently, when deserialize a RexNode fails, calcite returns a null value,
causing NPE in somewhere else. So we cannot get any information about the
SqlOperator in the stacktrace. This makes hard to determine the reason when
deserialize a very long json string.
{noformat}
Caused by: java.lang.NullPointerException
at java.util.Objects.requireNonNull(Objects.java:203)
at
org.apache.calcite.rel.core.AggregateCall.(AggregateCall.java:98)
at
org.apache.calcite.rel.core.AggregateCall.create(AggregateCall.java:198)
at
org.apache.calcite.rel.externalize.RelJsonReader.toAggCall(RelJsonReader.java:289)
at
org.apache.calcite.rel.externalize.RelJsonReader.access$500(RelJsonReader.java:59)
at
org.apache.calcite.rel.externalize.RelJsonReader$2.getAggregateCalls(RelJsonReader.java:172)
at org.apache.calcite.rel.core.Aggregate.(Aggregate.java:220)
at
org.apache.calcite.rel.logical.LogicalAggregate.(LogicalAggregate.java:105)
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:264)
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:894)
at
org.apache.calcite.tools.Frameworks.lambda$withPlanner$0(Frameworks.java:131)
at
org.apache.calcite.prepare.CalcitePrepareImpl.perform(CalcitePrepareImpl.java:914)
at org.apache.calcite.tools.Frameworks.withPrepare(Frameworks.java:180)
... 67 more
{noformat}
Maybe it's better to throw exception instead of return null.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4177) Throw exception when deserialize SqlOperator fails, do not return null
[
https://issues.apache.org/jira/browse/CALCITE-4177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin updated CALCITE-4177:
-
Description:
Currently, when deserialize a RexNode fails, calcite returns a null value,
causing NPE in somewhere else. So we cannot get any information about the
SqlOperator in the stacktrace. This makes it hard to determine the reason
when deserialize a very long json string.
{noformat}
Caused by: java.lang.NullPointerException
at java.util.Objects.requireNonNull(Objects.java:203)
at
org.apache.calcite.rel.core.AggregateCall.(AggregateCall.java:98)
at
org.apache.calcite.rel.core.AggregateCall.create(AggregateCall.java:198)
at
org.apache.calcite.rel.externalize.RelJsonReader.toAggCall(RelJsonReader.java:289)
at
org.apache.calcite.rel.externalize.RelJsonReader.access$500(RelJsonReader.java:59)
at
org.apache.calcite.rel.externalize.RelJsonReader$2.getAggregateCalls(RelJsonReader.java:172)
at org.apache.calcite.rel.core.Aggregate.(Aggregate.java:220)
at
org.apache.calcite.rel.logical.LogicalAggregate.(LogicalAggregate.java:105)
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:264)
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:894)
at
org.apache.calcite.tools.Frameworks.lambda$withPlanner$0(Frameworks.java:131)
at
org.apache.calcite.prepare.CalcitePrepareImpl.perform(CalcitePrepareImpl.java:914)
at org.apache.calcite.tools.Frameworks.withPrepare(Frameworks.java:180)
... 67 more
{noformat}
Maybe it's better to throw exception instead of return null.
was:
Currently, when deserialize a RexNode fails, calcite returns a null value,
causing NPE in somewhere else. So we cannot get any information about the
SqlOperator in the stacktrace. This makes hard to determine the reason when
deserialize a very long json string.
{noformat}
Caused by: java.lang.NullPointerException
at java.util.Objects.requireNonNull(Objects.java:203)
at
org.apache.calcite.rel.core.AggregateCall.(AggregateCall.java:98)
at
org.apache.calcite.rel.core.AggregateCall.create(AggregateCall.java:198)
at
org.apache.calcite.rel.externalize.RelJsonReader.toAggCall(RelJsonReader.java:289)
at
org.apache.calcite.rel.externalize.RelJsonReader.access$500(RelJsonReader.java:59)
at
org.apache.calcite.rel.externalize.RelJsonReader$2.getAggregateCalls(RelJsonReader.java:172)
at org.apache.calcite.rel.core.Aggregate.(Aggregate.java:220)
at
org.apache.calcite.rel.logical.LogicalAggregate.(LogicalAggregate.java:105)
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:264)
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:894)
at
org.apache.calcite.tools.Frameworks.lambda$withPlanner$0(Frameworks.java:131)
at
org.apache.calcite.prepare.CalcitePrepareImpl.perform(CalcitePrepareImpl.java:914)
at org.apache.calcite.tools.Frameworks.withPrepare(Frameworks.java:180)
... 67 more
{noformat}
Maybe it's better to throw exception instead of return null.
> Throw exception when deserialize SqlOperator fails, do not return null
> --
>
> Key: CALCITE-4177
> URL: https://issues.apache.org/jira/browse/CALCITE-4177
> Project: Calcite
> Issue Type: Improvement
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Minor
>
> Currently, when deserialize a RexNode fails, calcite returns a null value,
> causing NPE in somewhere el
[jira] [Updated] (CALCITE-4177) Throw exception when deserialize SqlOperator fails, do not return null
[
https://issues.apache.org/jira/browse/CALCITE-4177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin updated CALCITE-4177:
-
Description:
Currently, when deserialize a RexNode fails, calcite returns a null value,
causing NPE in somewhere else. So we cannot get any information about the
SqlOperator in the stacktrace. This makes it hard to determine the reason
when deserialize a very long json string.
{noformat}
Caused by: java.lang.NullPointerException
at java.util.Objects.requireNonNull(Objects.java:203)
at
org.apache.calcite.rel.core.AggregateCall.(AggregateCall.java:98)
at
org.apache.calcite.rel.core.AggregateCall.create(AggregateCall.java:198)
at
org.apache.calcite.rel.externalize.RelJsonReader.toAggCall(RelJsonReader.java:289)
at
org.apache.calcite.rel.externalize.RelJsonReader.access$500(RelJsonReader.java:59)
at
org.apache.calcite.rel.externalize.RelJsonReader$2.getAggregateCalls(RelJsonReader.java:172)
at org.apache.calcite.rel.core.Aggregate.(Aggregate.java:220)
at
org.apache.calcite.rel.logical.LogicalAggregate.(LogicalAggregate.java:105)
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:264)
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:894)
at
org.apache.calcite.tools.Frameworks.lambda$withPlanner$0(Frameworks.java:131)
at
org.apache.calcite.prepare.CalcitePrepareImpl.perform(CalcitePrepareImpl.java:914)
at org.apache.calcite.tools.Frameworks.withPrepare(Frameworks.java:180)
... 67 more
{noformat}
Maybe it's better to throw exception instead of return null, adding the name,
kind, and syntax in the error message
was:
Currently, when deserialize a RexNode fails, calcite returns a null value,
causing NPE in somewhere else. So we cannot get any information about the
SqlOperator in the stacktrace. This makes it hard to determine the reason
when deserialize a very long json string.
{noformat}
Caused by: java.lang.NullPointerException
at java.util.Objects.requireNonNull(Objects.java:203)
at
org.apache.calcite.rel.core.AggregateCall.(AggregateCall.java:98)
at
org.apache.calcite.rel.core.AggregateCall.create(AggregateCall.java:198)
at
org.apache.calcite.rel.externalize.RelJsonReader.toAggCall(RelJsonReader.java:289)
at
org.apache.calcite.rel.externalize.RelJsonReader.access$500(RelJsonReader.java:59)
at
org.apache.calcite.rel.externalize.RelJsonReader$2.getAggregateCalls(RelJsonReader.java:172)
at org.apache.calcite.rel.core.Aggregate.(Aggregate.java:220)
at
org.apache.calcite.rel.logical.LogicalAggregate.(LogicalAggregate.java:105)
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:264)
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:894)
at
org.apache.calcite.tools.Frameworks.lambda$withPlanner$0(Frameworks.java:131)
at
org.apache.calcite.prepare.CalcitePrepareImpl.perform(CalcitePrepareImpl.java:914)
at org.apache.calcite.tools.Frameworks.withPrepare(Frameworks.java:180)
... 67 more
{noformat}
Maybe it's better to throw exception instead of return null.
> Throw exception when deserialize SqlOperator fails, do not return null
> --
>
> Key: CALCITE-4177
> URL: https://issues.apache.org/jira/browse/CALCITE-4177
> Project: Calcite
> Issue Type: Improvement
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Minor
>
> Currently, when deserialize a RexNode fails,
[jira] [Updated] (CALCITE-4182) MV recognition fails when query has constant filter for group by list in mv, but without group by
[
https://issues.apache.org/jira/browse/CALCITE-4182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin updated CALCITE-4182:
-
Description:
Mv re
{noformat}
@Test void testConstantFilterInAgg() {
final String mv = ""
+ "select \"name\", count(distinct \"deptno\") as cnt\n"
+ "from \"emps\" group by \"name\"";
final String query = ""
+ "select count(distinct \"deptno\") as cnt\n"
+ "from \"emps\" where \"name\" = 'hello'";
sql(mv, query).ok();
}
{noformat}
was:
{noformat}
@Test void testConstantFilterInAgg() {
final String mv = ""
+ "select \"name\", count(distinct \"deptno\") as cnt\n"
+ "from \"emps\" group by \"name\"";
final String query = ""
+ "select count(distinct \"deptno\") as cnt\n"
+ "from \"emps\" where \"name\" = 'hello'";
sql(mv, query).ok();
}
{noformat}
> MV recognition fails when query has constant filter for group by list in mv,
> but without group by
> -
>
> Key: CALCITE-4182
> URL: https://issues.apache.org/jira/browse/CALCITE-4182
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Priority: Major
>
> Mv re
> {noformat}
> @Test void testConstantFilterInAgg() {
> final String mv = ""
> + "select \"name\", count(distinct \"deptno\") as cnt\n"
> + "from \"emps\" group by \"name\"";
> final String query = ""
> + "select count(distinct \"deptno\") as cnt\n"
> + "from \"emps\" where \"name\" = 'hello'";
> sql(mv, query).ok();
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-4182) MV recognition fails when query has constant filter for group by list in mv, but without group by
Wang Yanlin created CALCITE-4182: Summary: MV recognition fails when query has constant filter for group by list in mv, but without group by Key: CALCITE-4182 URL: https://issues.apache.org/jira/browse/CALCITE-4182 Project: Calcite Issue Type: Bug Reporter: Wang Yanlin -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4182) MV recognition fails when query has constant filter for group by list in mv, but without group by
[
https://issues.apache.org/jira/browse/CALCITE-4182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin updated CALCITE-4182:
-
Description:
{noformat}
@Test void testConstantFilterInAgg() {
final String mv = ""
+ "select \"name\", count(distinct \"deptno\") as cnt\n"
+ "from \"emps\" group by \"name\"";
final String query = ""
+ "select count(distinct \"deptno\") as cnt\n"
+ "from \"emps\" where \"name\" = 'hello'";
sql(mv, query).ok();
}
{noformat}
> MV recognition fails when query has constant filter for group by list in mv,
> but without group by
> -
>
> Key: CALCITE-4182
> URL: https://issues.apache.org/jira/browse/CALCITE-4182
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Priority: Major
>
> {noformat}
> @Test void testConstantFilterInAgg() {
> final String mv = ""
> + "select \"name\", count(distinct \"deptno\") as cnt\n"
> + "from \"emps\" group by \"name\"";
> final String query = ""
> + "select count(distinct \"deptno\") as cnt\n"
> + "from \"emps\" where \"name\" = 'hello'";
> sql(mv, query).ok();
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4182) MV recognition fails when query has constant filter for group by list in mv, but without group by
[
https://issues.apache.org/jira/browse/CALCITE-4182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin updated CALCITE-4182:
-
Description:
MV recognition fails when query has constant filter for group by list in mv,
but has no group by itself.
{noformat}
@Test void testConstantFilterInAgg() {
final String mv = ""
+ "select \"name\", count(distinct \"deptno\") as cnt\n"
+ "from \"emps\" group by \"name\"";
final String query = ""
+ "select count(distinct \"deptno\") as cnt\n"
+ "from \"emps\" where \"name\" = 'hello'";
sql(mv, query).ok();
}
{noformat}
This case fails, however we can see that, we can rewrite the query with mv like
this, suppose *mv* is the name of the table.
{noformat}
select cnt from mv where name = 'hello';
{noformat}
However, this query has the same semantics with the query in the case, using
this query for mv recognition, the case will success
{noformat}
final String query = ""
+ "select cnt from(\n"
+ " select \"name\", count(distinct \"deptno\") as cnt "
+ " from \"emps\" group by \"name\") t\n"
+ "where \"name\" = 'hello'";
{noformat}
But we cannot force users to only write their queries in this way, so maybe we
need a rule to expand aggregate group by list with constant filter condition.
was:
Mv re
{noformat}
@Test void testConstantFilterInAgg() {
final String mv = ""
+ "select \"name\", count(distinct \"deptno\") as cnt\n"
+ "from \"emps\" group by \"name\"";
final String query = ""
+ "select count(distinct \"deptno\") as cnt\n"
+ "from \"emps\" where \"name\" = 'hello'";
sql(mv, query).ok();
}
{noformat}
> MV recognition fails when query has constant filter for group by list in mv,
> but without group by
> -
>
> Key: CALCITE-4182
> URL: https://issues.apache.org/jira/browse/CALCITE-4182
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Priority: Major
>
> MV recognition fails when query has constant filter for group by list in mv,
> but has no group by itself.
>
> {noformat}
> @Test void testConstantFilterInAgg() {
> final String mv = ""
> + "select \"name\", count(distinct \"deptno\") as cnt\n"
> + "from \"emps\" group by \"name\"";
> final String query = ""
> + "select count(distinct \"deptno\") as cnt\n"
> + "from \"emps\" where \"name\" = 'hello'";
> sql(mv, query).ok();
> }
> {noformat}
> This case fails, however we can see that, we can rewrite the query with mv
> like this, suppose *mv* is the name of the table.
> {noformat}
> select cnt from mv where name = 'hello';
> {noformat}
> However, this query has the same semantics with the query in the case, using
> this query for mv recognition, the case will success
> {noformat}
> final String query = ""
> + "select cnt from(\n"
> + " select \"name\", count(distinct \"deptno\") as cnt "
> + " from \"emps\" group by \"name\") t\n"
> + "where \"name\" = 'hello'";
> {noformat}
> But we cannot force users to only write their queries in this way, so maybe
> we need a rule to expand aggregate group by list with constant filter
> condition.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (CALCITE-4182) MV recognition fails when query has constant filter for group by list in mv, but without group by
[
https://issues.apache.org/jira/browse/CALCITE-4182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin reassigned CALCITE-4182:
Assignee: Wang Yanlin
> MV recognition fails when query has constant filter for group by list in mv,
> but without group by
> -
>
> Key: CALCITE-4182
> URL: https://issues.apache.org/jira/browse/CALCITE-4182
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Major
>
> MV recognition fails when query has constant filter for group by list in mv,
> but has no group by itself.
>
> {noformat}
> @Test void testConstantFilterInAgg() {
> final String mv = ""
> + "select \"name\", count(distinct \"deptno\") as cnt\n"
> + "from \"emps\" group by \"name\"";
> final String query = ""
> + "select count(distinct \"deptno\") as cnt\n"
> + "from \"emps\" where \"name\" = 'hello'";
> sql(mv, query).ok();
> }
> {noformat}
> This case fails, however we can see that, we can rewrite the query with mv
> like this, suppose *mv* is the name of the table.
> {noformat}
> select cnt from mv where name = 'hello';
> {noformat}
> However, this query has the same semantics with the query in the case, using
> this query for mv recognition, the case will success
> {noformat}
> final String query = ""
> + "select cnt from(\n"
> + " select \"name\", count(distinct \"deptno\") as cnt "
> + " from \"emps\" group by \"name\") t\n"
> + "where \"name\" = 'hello'";
> {noformat}
> But we cannot force users to only write their queries in this way, so maybe
> we need a rule to expand aggregate group by list with constant filter
> condition.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4182) MV recognition fails when query has constant filter for group by list in mv, but without group by
[
https://issues.apache.org/jira/browse/CALCITE-4182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin updated CALCITE-4182:
-
Description:
MV recognition fails when query has constant filter for group by list in mv,
but has no group by itself.
{noformat}
@Test void testConstantFilterInAgg() {
final String mv = ""
+ "select \"name\", count(distinct \"deptno\") as cnt\n"
+ "from \"emps\" group by \"name\"";
final String query = ""
+ "select count(distinct \"deptno\") as cnt\n"
+ "from \"emps\" where \"name\" = 'hello'";
sql(mv, query).ok();
}
{noformat}
This case fails, however we can see that, we can rewrite the query with mv like
this, suppose *mv* is the name of the table.
{noformat}
select cnt from mv where name = 'hello';
{noformat}
However, this query has the same semantics with the query in the case, using
this query for mv recognition, the case will success
{noformat}
final String query = ""
+ "select cnt from(\n"
+ " select \"name\", count(distinct \"deptno\") as cnt "
+ " from \"emps\" group by \"name\") t\n"
+ "where \"name\" = 'hello'";
{noformat}
But we cannot force users to only write their queries in this way, so maybe we
need to enhance the mv recognition ability of
{{AggregateOnCalcToAggregateUnifyRule to cover this case.}}
was:
MV recognition fails when query has constant filter for group by list in mv,
but has no group by itself.
{noformat}
@Test void testConstantFilterInAgg() {
final String mv = ""
+ "select \"name\", count(distinct \"deptno\") as cnt\n"
+ "from \"emps\" group by \"name\"";
final String query = ""
+ "select count(distinct \"deptno\") as cnt\n"
+ "from \"emps\" where \"name\" = 'hello'";
sql(mv, query).ok();
}
{noformat}
This case fails, however we can see that, we can rewrite the query with mv like
this, suppose *mv* is the name of the table.
{noformat}
select cnt from mv where name = 'hello';
{noformat}
However, this query has the same semantics with the query in the case, using
this query for mv recognition, the case will success
{noformat}
final String query = ""
+ "select cnt from(\n"
+ " select \"name\", count(distinct \"deptno\") as cnt "
+ " from \"emps\" group by \"name\") t\n"
+ "where \"name\" = 'hello'";
{noformat}
But we cannot force users to only write their queries in this way, so maybe we
need a rule to expand aggregate group by list with constant filter condition.
> MV recognition fails when query has constant filter for group by list in mv,
> but without group by
> -
>
> Key: CALCITE-4182
> URL: https://issues.apache.org/jira/browse/CALCITE-4182
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> MV recognition fails when query has constant filter for group by list in mv,
> but has no group by itself.
> {noformat}
> @Test void testConstantFilterInAgg() {
> final String mv = ""
> + "select \"name\", count(distinct \"deptno\") as cnt\n"
> + "from \"emps\" group by \"name\"";
> final String query = ""
> + "select count(distinct \"deptno\") as cnt\n"
> + "from \"emps\" where \"name\" = 'hello'";
> sql(mv, query).ok();
> }
> {noformat}
> This case fails, however we can see that, we can rewrite the query with mv
> like this, suppose *mv* is the name of the table.
> {noformat}
> select cnt from mv where name = 'hello';
> {noformat}
> However, this query has the same semantics with the query in the case, using
> this query for mv recognition, the case will success
> {noformat}
> final String query = ""
> + "select cnt from(\n"
> + " select \"name\", count(distinct \"deptno\") as cnt "
> + " from \"emps\" group by \"name\") t\n"
> + "where \"name\" = 'hello'";
> {noformat}
> But we cannot force users to only write their queries in this way, so maybe
> we need to enhance the mv recognition ability of
> {{AggregateOnCalcToAggregateUnifyRule to cover this case.}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CALCITE-4182) MV recognition fails when query has constant filter for group by list in mv, but without group by
[
https://issues.apache.org/jira/browse/CALCITE-4182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin resolved CALCITE-4182.
--
Resolution: Fixed
> MV recognition fails when query has constant filter for group by list in mv,
> but without group by
> -
>
> Key: CALCITE-4182
> URL: https://issues.apache.org/jira/browse/CALCITE-4182
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Major
> Labels: pull-request-available
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> MV recognition fails when query has constant filter for group by list in mv,
> but has no group by itself.
> {noformat}
> @Test void testConstantFilterInAgg() {
> final String mv = ""
> + "select \"name\", count(distinct \"deptno\") as cnt\n"
> + "from \"emps\" group by \"name\"";
> final String query = ""
> + "select count(distinct \"deptno\") as cnt\n"
> + "from \"emps\" where \"name\" = 'hello'";
> sql(mv, query).ok();
> }
> {noformat}
> This case fails, however we can see that, we can rewrite the query with mv
> like this, suppose *mv* is the name of the table.
> {noformat}
> select cnt from mv where name = 'hello';
> {noformat}
> However, this query has the same semantics with the query in the case, using
> this query for mv recognition, the case will success
> {noformat}
> final String query = ""
> + "select cnt from(\n"
> + " select \"name\", count(distinct \"deptno\") as cnt "
> + " from \"emps\" group by \"name\") t\n"
> + "where \"name\" = 'hello'";
> {noformat}
> But we cannot force users to only write their queries in this way, so maybe
> we need to enhance the mv recognition ability of
> {{AggregateOnCalcToAggregateUnifyRule to cover this case.}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4182) MV recognition fails when query has constant filter for group by list in mv, but without group by
[
https://issues.apache.org/jira/browse/CALCITE-4182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17196989#comment-17196989
]
Wang Yanlin commented on CALCITE-4182:
--
Fixed in
https://github.com/apache/calcite/commit/8250798e4107c639dad122baf868137b35032001
> MV recognition fails when query has constant filter for group by list in mv,
> but without group by
> -
>
> Key: CALCITE-4182
> URL: https://issues.apache.org/jira/browse/CALCITE-4182
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Major
> Labels: pull-request-available
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> MV recognition fails when query has constant filter for group by list in mv,
> but has no group by itself.
> {noformat}
> @Test void testConstantFilterInAgg() {
> final String mv = ""
> + "select \"name\", count(distinct \"deptno\") as cnt\n"
> + "from \"emps\" group by \"name\"";
> final String query = ""
> + "select count(distinct \"deptno\") as cnt\n"
> + "from \"emps\" where \"name\" = 'hello'";
> sql(mv, query).ok();
> }
> {noformat}
> This case fails, however we can see that, we can rewrite the query with mv
> like this, suppose *mv* is the name of the table.
> {noformat}
> select cnt from mv where name = 'hello';
> {noformat}
> However, this query has the same semantics with the query in the case, using
> this query for mv recognition, the case will success
> {noformat}
> final String query = ""
> + "select cnt from(\n"
> + " select \"name\", count(distinct \"deptno\") as cnt "
> + " from \"emps\" group by \"name\") t\n"
> + "where \"name\" = 'hello'";
> {noformat}
> But we cannot force users to only write their queries in this way, so maybe
> we need to enhance the mv recognition ability of
> {{AggregateOnCalcToAggregateUnifyRule to cover this case.}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-4273) Support get expression lineage for Calc
Wang Yanlin created CALCITE-4273: Summary: Support get expression lineage for Calc Key: CALCITE-4273 URL: https://issues.apache.org/jira/browse/CALCITE-4273 Project: Calcite Issue Type: Improvement Reporter: Wang Yanlin -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (CALCITE-4273) Support get expression lineage for Calc
[ https://issues.apache.org/jira/browse/CALCITE-4273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wang Yanlin reassigned CALCITE-4273: Assignee: Wang Yanlin > Support get expression lineage for Calc > --- > > Key: CALCITE-4273 > URL: https://issues.apache.org/jira/browse/CALCITE-4273 > Project: Calcite > Issue Type: Improvement >Reporter: Wang Yanlin >Assignee: Wang Yanlin >Priority: Minor > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-4374) Support materialized view recognition when query distinct aggregate on target GROUP BY column
Wang Yanlin created CALCITE-4374: Summary: Support materialized view recognition when query distinct aggregate on target GROUP BY column Key: CALCITE-4374 URL: https://issues.apache.org/jira/browse/CALCITE-4374 Project: Calcite Issue Type: Improvement Reporter: Wang Yanlin -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4374) Support materialized view recognition when query distinct aggregate on target GROUP BY column
[
https://issues.apache.org/jira/browse/CALCITE-4374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin updated CALCITE-4374:
-
Description:
When query distinct aggregate on the column, which is in the group by list of
target.
Ma
{noformat}
@Test void testQueryDistinctColumnInTargetGroupByList() {
final String mv = ""
+ "select \"name\", \"deptno\" as cnt "
+ "from \"emps\" group by \"name\", \"deptno\"";
final String query = ""
+ "select \"name\", count(distinct \"deptno\")\n"
+ "from \"emps\" group by \"name\"";
sql(mv, query).ok();
}
{noformat}
> Support materialized view recognition when query distinct aggregate on target
> GROUP BY column
> -
>
> Key: CALCITE-4374
> URL: https://issues.apache.org/jira/browse/CALCITE-4374
> Project: Calcite
> Issue Type: Improvement
>Reporter: Wang Yanlin
>Priority: Major
>
> When query distinct aggregate on the column, which is in the group by list of
> target.
> Ma
> {noformat}
> @Test void testQueryDistinctColumnInTargetGroupByList() {
> final String mv = ""
> + "select \"name\", \"deptno\" as cnt "
> + "from \"emps\" group by \"name\", \"deptno\"";
> final String query = ""
> + "select \"name\", count(distinct \"deptno\")\n"
> + "from \"emps\" group by \"name\"";
> sql(mv, query).ok();
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4374) Support materialized view recognition when query distinct aggregate on target GROUP BY column
[
https://issues.apache.org/jira/browse/CALCITE-4374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin updated CALCITE-4374:
-
Description:
When query distinct aggregate on the column, which is in the group by list of
target.
Materialized view recognition should success.
See this case.
{noformat}
@Test void testQueryDistinctColumnInTargetGroupByList() {
final String mv = ""
+ "select \"name\", \"deptno\" "
+ "from \"emps\" group by \"name\", \"deptno\"";
final String query = ""
+ "select \"name\", count(distinct \"deptno\")\n"
+ "from \"emps\" group by \"name\"";
sql(mv, query).ok();
}
{noformat}
was:
When query distinct aggregate on the column, which is in the group by list of
target.
Ma
{noformat}
@Test void testQueryDistinctColumnInTargetGroupByList() {
final String mv = ""
+ "select \"name\", \"deptno\" as cnt "
+ "from \"emps\" group by \"name\", \"deptno\"";
final String query = ""
+ "select \"name\", count(distinct \"deptno\")\n"
+ "from \"emps\" group by \"name\"";
sql(mv, query).ok();
}
{noformat}
> Support materialized view recognition when query distinct aggregate on target
> GROUP BY column
> -
>
> Key: CALCITE-4374
> URL: https://issues.apache.org/jira/browse/CALCITE-4374
> Project: Calcite
> Issue Type: Improvement
>Reporter: Wang Yanlin
>Priority: Major
>
> When query distinct aggregate on the column, which is in the group by list of
> target.
> Materialized view recognition should success.
> See this case.
> {noformat}
> @Test void testQueryDistinctColumnInTargetGroupByList() {
> final String mv = ""
> + "select \"name\", \"deptno\" "
> + "from \"emps\" group by \"name\", \"deptno\"";
> final String query = ""
> + "select \"name\", count(distinct \"deptno\")\n"
> + "from \"emps\" group by \"name\"";
> sql(mv, query).ok();
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (CALCITE-4373) Count(distinct Col) materialized view recognition failed
[
https://issues.apache.org/jira/browse/CALCITE-4373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin closed CALCITE-4373.
Resolution: Duplicate
Same with https://issues.apache.org/jira/browse/CALCITE-4374
> Count(distinct Col) materialized view recognition failed
>
>
> Key: CALCITE-4373
> URL: https://issues.apache.org/jira/browse/CALCITE-4373
> Project: Calcite
> Issue Type: Wish
>Reporter: xzh_dz
>Priority: Major
> Attachments: image-2020-11-03-10-56-57-804.png
>
>
>
> {code:java}
> org.apache.calcite.test.MaterializedViewSubstitutionVisitorTest
> // code placeholder
> @Test void testCountDistinctInAgg() {
> final String mv = ""
> + "select \"name\", \"commission\", \"deptno\"\n"
> + "from \"emps\" group by \"name\", \"commission\", \"deptno\"";
> final String query = ""
> + "select \"name\", \"commission\", count(distinct \"deptno\") as cnt\n"
> + "from \"emps\" group by \"name\", \"commission\"";
> sql(mv, query).withChecker(
> resultContains(""
> + "LogicalCalc(expr#0..1=[{inputs}], expr#2=['hello':VARCHAR],
> expr#3=[CAST($t0)"
> + ":VARCHAR], expr#4=[=($t2, $t3)], CNT=[$t1], $condition=[$t4])\n"
> + " EnumerableTableScan(table=[[hr, MV0]])")).ok();
> }
> {code}
>
>
> Error:
> !image-2020-11-03-10-56-57-804.png|width=511,height=99!
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CALCITE-4273) Support get expression lineage for Calc
[ https://issues.apache.org/jira/browse/CALCITE-4273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wang Yanlin resolved CALCITE-4273. -- Resolution: Fixed > Support get expression lineage for Calc > --- > > Key: CALCITE-4273 > URL: https://issues.apache.org/jira/browse/CALCITE-4273 > Project: Calcite > Issue Type: Improvement >Reporter: Wang Yanlin >Assignee: Wang Yanlin >Priority: Minor > Labels: pull-request-available > Time Spent: 2h 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4273) Support get expression lineage for Calc
[ https://issues.apache.org/jira/browse/CALCITE-4273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17225746#comment-17225746 ] Wang Yanlin commented on CALCITE-4273: -- Fixed in https://github.com/apache/calcite/commit/2e9edae7fc57ab9c9c7c097008724ac99a1791a3 > Support get expression lineage for Calc > --- > > Key: CALCITE-4273 > URL: https://issues.apache.org/jira/browse/CALCITE-4273 > Project: Calcite > Issue Type: Improvement >Reporter: Wang Yanlin >Assignee: Wang Yanlin >Priority: Minor > Labels: pull-request-available > Time Spent: 2h 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-4376) Materialized view recognition fails when target output different column sequence with GROUP BY
Wang Yanlin created CALCITE-4376: Summary: Materialized view recognition fails when target output different column sequence with GROUP BY Key: CALCITE-4376 URL: https://issues.apache.org/jira/browse/CALCITE-4376 Project: Calcite Issue Type: Bug Reporter: Wang Yanlin -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4376) Materialized view recognition fails when target output different column sequence with GROUP BY
[ https://issues.apache.org/jira/browse/CALCITE-4376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wang Yanlin updated CALCITE-4376: - Description: When > Materialized view recognition fails when target output different column > sequence with GROUP BY > -- > > Key: CALCITE-4376 > URL: https://issues.apache.org/jira/browse/CALCITE-4376 > Project: Calcite > Issue Type: Bug >Reporter: Wang Yanlin >Priority: Major > > When -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4376) Materialized view recognition fails when target project different column sequence with GROUP BY
[ https://issues.apache.org/jira/browse/CALCITE-4376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wang Yanlin updated CALCITE-4376: - Summary: Materialized view recognition fails when target project different column sequence with GROUP BY (was: Materialized view recognition fails when target output different column sequence with GROUP BY) > Materialized view recognition fails when target project different column > sequence with GROUP BY > --- > > Key: CALCITE-4376 > URL: https://issues.apache.org/jira/browse/CALCITE-4376 > Project: Calcite > Issue Type: Bug >Reporter: Wang Yanlin >Priority: Major > > When -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4376) Materialized view recognition fails when target project different column sequence with GROUP BY
[
https://issues.apache.org/jira/browse/CALCITE-4376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin updated CALCITE-4376:
-
Description:
When target project a different column sequence with group by, materialized
view recognition will fail, see the case below
{noformat}
@Test void test() {
final String mv = "" +
"select \"deptno\", \"name\" from ("
+ "select \"name\", \"deptno\", \"commission\" as cnt\n"
+ "from \"emps\"\n"
+ " group by \"name\", \"deptno\", \"commission\") t";
final String query = ""
+ "select \"deptno\", \"commission\" as cnt\n"
+ "from \"emps\"\n"
+ "group by \"deptno\", \"commission\"";
sql(mv, query).withChecker(
resultContains(""
+ "EnumerableTableScan(table=[[hr, MV0]])")).ok();
}
{noformat}
After the call of "AggregateOnCalcToAggregateUnifyRule", the result query is
{noformat}
Holder
Aggregate(groupSet: {1, 2}, groupSets: [{1, 2}], calls: [])
Aggregate(groupSet: {0, 1, 2}, groupSets: [{0, 1, 2}], calls: [])
Calc(program: (expr#0..4=[{inputs}], name=[$t2], deptno=[$t1],
commission=[$t4]))
Scan(table: [hr, emps])
{noformat}
, and the target is
{noformat}
Calc(program: (expr#0..2=[{inputs}], deptno=[$t1], name=[$t0]))
Aggregate(groupSet: {0, 1, 2}, groupSets: [{0, 1, 2}], calls: [])
Calc(program: (expr#0..4=[{inputs}], name=[$t2], deptno=[$t1],
commission=[$t4]))
Scan(table: [hr, emps])
{noformat}
There is no match for
{noformat}
query descendant: Aggregate(groupSet: {1, 2}, groupSets: [{1, 2}], calls: [])
target descendant: Calc(program: (expr#0..2=[{inputs}], deptno=[$t1],
name=[$t0]))
{noformat}
and the recognition fails. Maybe always add a calc in the call result of
"AggregateOnCalcToAggregateUnifyRule", make the call result like this
{noformat}
Holder
Aggregate(groupSet: {1, 2}, groupSets: [{1, 2}], calls: [])
Calc () // always add a calc here
Aggregate(groupSet: {0, 1, 2}, groupSets: [{0, 1, 2}], calls: [])
Calc(program: (expr#0..4=[{inputs}], name=[$t2], deptno=[$t1],
commission=[$t4]))
Scan(table: [hr, emps])
{noformat}
was:When
> Materialized view recognition fails when target project different column
> sequence with GROUP BY
> ---
>
> Key: CALCITE-4376
> URL: https://issues.apache.org/jira/browse/CALCITE-4376
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Priority: Major
>
> When target project a different column sequence with group by, materialized
> view recognition will fail, see the case below
> {noformat}
> @Test void test() {
> final String mv = "" +
> "select \"deptno\", \"name\" from ("
> + "select \"name\", \"deptno\", \"commission\" as cnt\n"
> + "from \"emps\"\n"
> + " group by \"name\", \"deptno\", \"commission\") t";
> final String query = ""
> + "select \"deptno\", \"commission\" as cnt\n"
> + "from \"emps\"\n"
> + "group by \"deptno\", \"commission\"";
> sql(mv, query).withChecker(
> resultContains(""
> + "EnumerableTableScan(table=[[hr, MV0]])")).ok();
> }
> {noformat}
> After the call of "AggregateOnCalcToAggregateUnifyRule", the result query is
> {noformat}
> Holder
> Aggregate(groupSet: {1, 2}, groupSets: [{1, 2}], calls: [])
> Aggregate(groupSet: {0, 1, 2}, groupSets: [{0, 1, 2}], calls: [])
> Calc(program: (expr#0..4=[{inputs}], name=[$t2], deptno=[$t1],
> commission=[$t4]))
> Scan(table: [hr, emps])
> {noformat}
> , and the target is
> {noformat}
> Calc(program: (expr#0..2=[{inputs}], deptno=[$t1], name=[$t0]))
> Aggregate(groupSet: {0, 1, 2}, groupSets: [{0, 1, 2}], calls: [])
> Calc(program: (expr#0..4=[{inputs}], name=[$t2], deptno=[$t1],
> commission=[$t4]))
> Scan(table: [hr, emps])
> {noformat}
> There is no match for
> {noformat}
> query descendant: Aggregate(groupSet: {1, 2}, groupSets: [{1, 2}], calls: [])
> target descendant: Calc(program: (expr#0..2=[{inputs}], deptno=[$t1],
> name=[$t0]))
> {noformat}
> and the recognition fails. Maybe always add a calc in the call result of
> "AggregateOnCalcToAggregateUnifyRule", make the call result like this
> {noformat}
> Holder
> Aggregate(groupSet: {1, 2}, groupSets: [{1, 2}], calls: [])
> Calc () // always add a calc here
> Aggregate(groupSet: {0, 1, 2}, groupSets: [{0, 1, 2}], calls: [])
> Calc(program: (expr#0..4=[{inputs}], name=[$t2], deptno=[$t1],
> commission=[$t4]))
> Scan(table: [hr, emps])
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (CALCITE-4376) Materialized view recognition fails when target project different column sequence with GROUP BY
[
https://issues.apache.org/jira/browse/CALCITE-4376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin reassigned CALCITE-4376:
Assignee: Wang Yanlin
> Materialized view recognition fails when target project different column
> sequence with GROUP BY
> ---
>
> Key: CALCITE-4376
> URL: https://issues.apache.org/jira/browse/CALCITE-4376
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Major
>
> When target project a different column sequence with group by, materialized
> view recognition will fail, see the case below
> {noformat}
> @Test void test() {
> final String mv = "" +
> "select \"deptno\", \"name\" from ("
> + "select \"name\", \"deptno\", \"commission\" as cnt\n"
> + "from \"emps\"\n"
> + " group by \"name\", \"deptno\", \"commission\") t";
> final String query = ""
> + "select \"deptno\", \"commission\" as cnt\n"
> + "from \"emps\"\n"
> + "group by \"deptno\", \"commission\"";
> sql(mv, query).withChecker(
> resultContains(""
> + "EnumerableTableScan(table=[[hr, MV0]])")).ok();
> }
> {noformat}
> After the call of "AggregateOnCalcToAggregateUnifyRule", the result query is
> {noformat}
> Holder
> Aggregate(groupSet: {1, 2}, groupSets: [{1, 2}], calls: [])
> Aggregate(groupSet: {0, 1, 2}, groupSets: [{0, 1, 2}], calls: [])
> Calc(program: (expr#0..4=[{inputs}], name=[$t2], deptno=[$t1],
> commission=[$t4]))
> Scan(table: [hr, emps])
> {noformat}
> , and the target is
> {noformat}
> Calc(program: (expr#0..2=[{inputs}], deptno=[$t1], name=[$t0]))
> Aggregate(groupSet: {0, 1, 2}, groupSets: [{0, 1, 2}], calls: [])
> Calc(program: (expr#0..4=[{inputs}], name=[$t2], deptno=[$t1],
> commission=[$t4]))
> Scan(table: [hr, emps])
> {noformat}
> There is no match for
> {noformat}
> query descendant: Aggregate(groupSet: {1, 2}, groupSets: [{1, 2}], calls: [])
> target descendant: Calc(program: (expr#0..2=[{inputs}], deptno=[$t1],
> name=[$t0]))
> {noformat}
> and the recognition fails. Maybe always add a calc in the call result of
> "AggregateOnCalcToAggregateUnifyRule", make the call result like this
> {noformat}
> Holder
> Aggregate(groupSet: {1, 2}, groupSets: [{1, 2}], calls: [])
> Calc () // always add a calc here
> Aggregate(groupSet: {0, 1, 2}, groupSets: [{0, 1, 2}], calls: [])
> Calc(program: (expr#0..4=[{inputs}], name=[$t2], deptno=[$t1],
> commission=[$t4]))
> Scan(table: [hr, emps])
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CALCITE-4374) Support materialized view recognition when query distinct aggregate on target GROUP BY column
[
https://issues.apache.org/jira/browse/CALCITE-4374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin resolved CALCITE-4374.
--
Resolution: Fixed
> Support materialized view recognition when query distinct aggregate on target
> GROUP BY column
> -
>
> Key: CALCITE-4374
> URL: https://issues.apache.org/jira/browse/CALCITE-4374
> Project: Calcite
> Issue Type: Improvement
>Reporter: Wang Yanlin
>Priority: Major
> Labels: pull-request-available
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> When query distinct aggregate on the column, which is in the group by list of
> target.
> Materialized view recognition should success.
> See this case.
> {noformat}
> @Test void testQueryDistinctColumnInTargetGroupByList() {
> final String mv = ""
> + "select \"name\", \"deptno\" "
> + "from \"emps\" group by \"name\", \"deptno\"";
> final String query = ""
> + "select \"name\", count(distinct \"deptno\")\n"
> + "from \"emps\" group by \"name\"";
> sql(mv, query).ok();
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4374) Support materialized view recognition when query distinct aggregate on target GROUP BY column
[
https://issues.apache.org/jira/browse/CALCITE-4374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230322#comment-17230322
]
Wang Yanlin commented on CALCITE-4374:
--
Fixed in Fixed in
https://github.com/apache/calcite/commit/1e6b7425ec20e2bddc6331a21016475a43f9d995,
thx [~xzh_dz]
> Support materialized view recognition when query distinct aggregate on target
> GROUP BY column
> -
>
> Key: CALCITE-4374
> URL: https://issues.apache.org/jira/browse/CALCITE-4374
> Project: Calcite
> Issue Type: Improvement
>Reporter: Wang Yanlin
>Priority: Major
> Labels: pull-request-available
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> When query distinct aggregate on the column, which is in the group by list of
> target.
> Materialized view recognition should success.
> See this case.
> {noformat}
> @Test void testQueryDistinctColumnInTargetGroupByList() {
> final String mv = ""
> + "select \"name\", \"deptno\" "
> + "from \"emps\" group by \"name\", \"deptno\"";
> final String query = ""
> + "select \"name\", count(distinct \"deptno\")\n"
> + "from \"emps\" group by \"name\"";
> sql(mv, query).ok();
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CALCITE-4251) Get the origin column, even if it is derived
[
https://issues.apache.org/jira/browse/CALCITE-4251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin resolved CALCITE-4251.
--
Resolution: Fixed
Fixed in
https://github.com/apache/calcite/commit/f3c173c9220a83be0dfa0c80a39b015f384ffcd1,
thx [~xzh_dz]
> Get the origin column, even if it is derived
>
>
> Key: CALCITE-4251
> URL: https://issues.apache.org/jira/browse/CALCITE-4251
> Project: Calcite
> Issue Type: Wish
>Reporter: xzh_dz
>Priority: Major
> Labels: pull-request-available
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> A case:
> {code:java}
> final String sql1 = ""
> + "select empno, sum(sal) as all_sal\n"
> + "from emp\n"
> + "group by empno";
> {code}
> When i try to get the `all_sal` origin column field,it will return null and
> it is derived. we always get the origin column although it is derived. We
> should overload this method and determine whether the column is derived by
> setting parameters.
> org.apache.calcite.rel.metadata.RelMetadataQuery#getColumnOrigin
> {code:java}
> // code placeholder
> public RelColumnOrigin getColumnOrigin(RelNode rel, int column) {
> final Set origins = getColumnOrigins(rel, column);
> if (origins == null || origins.size() != 1) {
> return null;
> }
> final RelColumnOrigin origin = Iterables.getOnlyElement(origins);
> return origin.isDerived() ? null : origin;
> }
> {code}
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CALCITE-4005) Support Calc and SetOp operator in RelMdAllPredicates
[ https://issues.apache.org/jira/browse/CALCITE-4005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wang Yanlin resolved CALCITE-4005. -- Resolution: Fixed Fixed in https://github.com/apache/calcite/commit/99251a51842483bc80688364195a159b740bd53f, thx [~xzh_dz] > Support Calc and SetOp operator in RelMdAllPredicates > - > > Key: CALCITE-4005 > URL: https://issues.apache.org/jira/browse/CALCITE-4005 > Project: Calcite > Issue Type: Wish >Reporter: xzh_dz >Priority: Major > Labels: pull-request-available > Time Spent: 2.5h > Remaining Estimate: 0h > > Support calc operator in RelMdAllPredicates > and also support setOp operator. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4376) Materialized view recognition fails when target project different column sequence with GROUP BY
[
https://issues.apache.org/jira/browse/CALCITE-4376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin updated CALCITE-4376:
-
Description:
When target project a different column sequence with group by, materialized
view recognition will fail, see the case below
{noformat}
@Test void testDifferentGroupBySequence() {
final String mv = "" +
"select \"deptno\", \"name\" from ("
+ "select \"name\", \"deptno\", \"commission\"\n"
+ "from \"emps\"\n"
+ " group by \"name\", \"deptno\", \"commission\") t";
final String query = ""
+ "select \"deptno\", \"name\"\n"
+ "from \"emps\"\n"
+ "group by \"deptno\", \"name\"";
sql(mv, query).withChecker(
resultContains(""
+ "EnumerableTableScan(table=[[hr, MV0]])")).ok();
}
{noformat}
After the call of "AggregateOnCalcToAggregateUnifyRule", the result query is
{noformat}
Holder
Calc(program: (expr#0..1=[{inputs}], deptno=[$t1], name=[$t0]))
Aggregate(groupSet: {0, 1}, groupSets: [{0, 1}], calls: [])
Aggregate(groupSet: {0, 1, 2}, groupSets: [{0, 1, 2}], calls: [])
Calc(program: (expr#0..4=[{inputs}], name=[$t2], deptno=[$t1],
commission=[$t4]))
Scan(table: [hr, emps])
{noformat}
, and the target is
{noformat}
Calc(program: (expr#0..2=[{inputs}], deptno=[$t1], name=[$t0]))
Aggregate(groupSet: {0, 1, 2}, groupSets: [{0, 1, 2}], calls: [])
Calc(program: (expr#0..4=[{inputs}], name=[$t2], deptno=[$t1],
commission=[$t4]))
Scan(table: [hr, emps])
{noformat}
There is no match for
{noformat}
query descendant: Aggregate(groupSet: {1, 2}, groupSets: [{1, 2}], calls: [])
target descendant: Calc(program: (expr#0..2=[{inputs}], deptno=[$t1],
name=[$t0]))
{noformat}
and the recognition fails. Maybe always add a calc in the call result of
"AggregateOnCalcToAggregateUnifyRule", make the call result like this
{noformat}
Holder
Calc(program: (expr#0..1=[{inputs}], deptno=[$t1], name=[$t0]))
Aggregate(groupSet: {0, 1}, groupSets: [{0, 1}], calls: [])
Calc () // always add a calc here
Aggregate(groupSet: {0, 1, 2}, groupSets: [{0, 1, 2}], calls: [])
Calc(program: (expr#0..4=[{inputs}], name=[$t2], deptno=[$t1],
commission=[$t4]))
Scan(table: [hr, emps])
{noformat}
was:
When target project a different column sequence with group by, materialized
view recognition will fail, see the case below
{noformat}
@Test void test() {
final String mv = "" +
"select \"deptno\", \"name\" from ("
+ "select \"name\", \"deptno\", \"commission\" as cnt\n"
+ "from \"emps\"\n"
+ " group by \"name\", \"deptno\", \"commission\") t";
final String query = ""
+ "select \"deptno\", \"commission\" as cnt\n"
+ "from \"emps\"\n"
+ "group by \"deptno\", \"commission\"";
sql(mv, query).withChecker(
resultContains(""
+ "EnumerableTableScan(table=[[hr, MV0]])")).ok();
}
{noformat}
After the call of "AggregateOnCalcToAggregateUnifyRule", the result query is
{noformat}
Holder
Aggregate(groupSet: {1, 2}, groupSets: [{1, 2}], calls: [])
Aggregate(groupSet: {0, 1, 2}, groupSets: [{0, 1, 2}], calls: [])
Calc(program: (expr#0..4=[{inputs}], name=[$t2], deptno=[$t1],
commission=[$t4]))
Scan(table: [hr, emps])
{noformat}
, and the target is
{noformat}
Calc(program: (expr#0..2=[{inputs}], deptno=[$t1], name=[$t0]))
Aggregate(groupSet: {0, 1, 2}, groupSets: [{0, 1, 2}], calls: [])
Calc(program: (expr#0..4=[{inputs}], name=[$t2], deptno=[$t1],
commission=[$t4]))
Scan(table: [hr, emps])
{noformat}
There is no match for
{noformat}
query descendant: Aggregate(groupSet: {1, 2}, groupSets: [{1, 2}], calls: [])
target descendant: Calc(program: (expr#0..2=[{inputs}], deptno=[$t1],
name=[$t0]))
{noformat}
and the recognition fails. Maybe always add a calc in the call result of
"AggregateOnCalcToAggregateUnifyRule", make the call result like this
{noformat}
Holder
Aggregate(groupSet: {1, 2}, groupSets: [{1, 2}], calls: [])
Calc () // always add a calc here
Aggregate(groupSet: {0, 1, 2}, groupSets: [{0, 1, 2}], calls: [])
Calc(program: (expr#0..4=[{inputs}], name=[$t2], deptno=[$t1],
commission=[$t4]))
Scan(table: [hr, emps])
{noformat}
> Materialized view recognition fails when target project different column
> sequence with GROUP BY
> ---
>
> Key: CALCITE-4376
> URL: https://issues.apache.org/jira/browse/CALCITE-4376
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Major
>
> When target project a different column sequence with group by, materialized
> view recognition will fail, see the c
[jira] [Updated] (CALCITE-4376) Materialized view recognition fails when target project different column sequence with GROUP BY
[
https://issues.apache.org/jira/browse/CALCITE-4376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin updated CALCITE-4376:
-
Description:
When target project a different column sequence with group by, materialized
view recognition will fail, see the case below
{noformat}
@Test void testDifferentGroupBySequence() {
final String mv = "" +
"select \"deptno\", \"name\" from ("
+ "select \"name\", \"deptno\", \"commission\"\n"
+ "from \"emps\"\n"
+ " group by \"name\", \"deptno\", \"commission\") t";
final String query = ""
+ "select \"deptno\", \"name\"\n"
+ "from \"emps\"\n"
+ "group by \"deptno\", \"name\"";
sql(mv, query).withChecker(
resultContains(""
+ "EnumerableTableScan(table=[[hr, MV0]])")).ok();
}
{noformat}
was:
When target project a different column sequence with group by, materialized
view recognition will fail, see the case below
{noformat}
@Test void testDifferentGroupBySequence() {
final String mv = "" +
"select \"deptno\", \"name\" from ("
+ "select \"name\", \"deptno\", \"commission\"\n"
+ "from \"emps\"\n"
+ " group by \"name\", \"deptno\", \"commission\") t";
final String query = ""
+ "select \"deptno\", \"name\"\n"
+ "from \"emps\"\n"
+ "group by \"deptno\", \"name\"";
sql(mv, query).withChecker(
resultContains(""
+ "EnumerableTableScan(table=[[hr, MV0]])")).ok();
}
{noformat}
After the call of "AggregateOnCalcToAggregateUnifyRule", the result query is
{noformat}
Holder
Calc(program: (expr#0..1=[{inputs}], deptno=[$t1], name=[$t0]))
Aggregate(groupSet: {0, 1}, groupSets: [{0, 1}], calls: [])
Aggregate(groupSet: {0, 1, 2}, groupSets: [{0, 1, 2}], calls: [])
Calc(program: (expr#0..4=[{inputs}], name=[$t2], deptno=[$t1],
commission=[$t4]))
Scan(table: [hr, emps])
{noformat}
, and the target is
{noformat}
Calc(program: (expr#0..2=[{inputs}], deptno=[$t1], name=[$t0]))
Aggregate(groupSet: {0, 1, 2}, groupSets: [{0, 1, 2}], calls: [])
Calc(program: (expr#0..4=[{inputs}], name=[$t2], deptno=[$t1],
commission=[$t4]))
Scan(table: [hr, emps])
{noformat}
There is no match for
{noformat}
query descendant: Aggregate(groupSet: {1, 2}, groupSets: [{1, 2}], calls: [])
target descendant: Calc(program: (expr#0..2=[{inputs}], deptno=[$t1],
name=[$t0]))
{noformat}
and the recognition fails. Maybe always add a calc in the call result of
"AggregateOnCalcToAggregateUnifyRule", make the call result like this
{noformat}
Holder
Calc(program: (expr#0..1=[{inputs}], deptno=[$t1], name=[$t0]))
Aggregate(groupSet: {0, 1}, groupSets: [{0, 1}], calls: [])
Calc () // always add a calc here
Aggregate(groupSet: {0, 1, 2}, groupSets: [{0, 1, 2}], calls: [])
Calc(program: (expr#0..4=[{inputs}], name=[$t2], deptno=[$t1],
commission=[$t4]))
Scan(table: [hr, emps])
{noformat}
> Materialized view recognition fails when target project different column
> sequence with GROUP BY
> ---
>
> Key: CALCITE-4376
> URL: https://issues.apache.org/jira/browse/CALCITE-4376
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Major
>
> When target project a different column sequence with group by, materialized
> view recognition will fail, see the case below
> {noformat}
> @Test void testDifferentGroupBySequence() {
> final String mv = "" +
> "select \"deptno\", \"name\" from ("
> + "select \"name\", \"deptno\", \"commission\"\n"
> + "from \"emps\"\n"
> + " group by \"name\", \"deptno\", \"commission\") t";
> final String query = ""
> + "select \"deptno\", \"name\"\n"
> + "from \"emps\"\n"
> + "group by \"deptno\", \"name\"";
> sql(mv, query).withChecker(
> resultContains(""
> + "EnumerableTableScan(table=[[hr, MV0]])")).ok();
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4376) Materialized view recognition fails when target project different columns with GROUP BY
[
https://issues.apache.org/jira/browse/CALCITE-4376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin updated CALCITE-4376:
-
Summary: Materialized view recognition fails when target project different
columns with GROUP BY (was: Materialized view recognition fails when target
project different column sequence with GROUP BY)
> Materialized view recognition fails when target project different columns
> with GROUP BY
> ---
>
> Key: CALCITE-4376
> URL: https://issues.apache.org/jira/browse/CALCITE-4376
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When target project a different column sequence with group by, materialized
> view recognition will fail, see the case below
> {noformat}
> @Test void testDifferentGroupBySequence() {
> final String mv = "" +
> "select \"deptno\", \"name\" from ("
> + "select \"name\", \"deptno\", \"commission\"\n"
> + "from \"emps\"\n"
> + " group by \"name\", \"deptno\", \"commission\") t";
> final String query = ""
> + "select \"deptno\", \"name\"\n"
> + "from \"emps\"\n"
> + "group by \"deptno\", \"name\"";
> sql(mv, query).withChecker(
> resultContains(""
> + "EnumerableTableScan(table=[[hr, MV0]])")).ok();
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-4584) Using function in partition by list of over window cause converting exception
Wang Yanlin created CALCITE-4584:
Summary: Using function in partition by list of over window cause
converting exception
Key: CALCITE-4584
URL: https://issues.apache.org/jira/browse/CALCITE-4584
Project: Calcite
Issue Type: Bug
Reporter: Wang Yanlin
When try to using function expr in the partition by list of over window in sql,
got
{noformat}
java.lang.UnsupportedOperationException: class
org.apache.calcite.sql.SqlBasicCall: CHAR_LENGTH(`ENAME`)
{noformat}
The stack trace is as follow
{noformat}
java.lang.RuntimeException: while converting CHAR_LENGTH(`EMP`.`ENAME`)
at
org.apache.calcite.sql2rel.ReflectiveConvertletTable.lambda$registerOpTypeMethod$3(ReflectiveConvertletTable.java:145)
at
org.apache.calcite.sql2rel.SqlNodeToRexConverterImpl.convertCall(SqlNodeToRexConverterImpl.java:62)
at
org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:5232)
at
org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:4486)
at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:161)
at
org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:5088)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertOver(SqlToRelConverter.java:2037)
at
org.apache.calcite.sql2rel.SqlToRelConverter.access$2000(SqlToRelConverter.java:224)
at
org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:5081)
at
org.apache.calcite.sql2rel.StandardConvertletTable.lambda$new$9(StandardConvertletTable.java:209)
at
org.apache.calcite.sql2rel.SqlNodeToRexConverterImpl.convertCall(SqlNodeToRexConverterImpl.java:62)
at
org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:5232)
at
org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:4486)
at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:161)
at
org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:5088)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectList(SqlToRelConverter.java:4327)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:707)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:664)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3538)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:589)
at
org.apache.calcite.test.SqlToRelTestBase$TesterImpl.convertSqlToRel(SqlToRelTestBase.java:638)
at
org.apache.calcite.test.SqlToRelTestBase$TesterImpl.assertConvertsTo(SqlToRelTestBase.java:799)
at
org.apache.calcite.test.SqlToRelConverterTest.testFunctionExprInOver(SqlToRelConverterTest.java:4196)
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.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:675)
at
org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:125)
at
org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:139)
at
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:131)
at
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:81)
at
org.junit.jupiter.engine.execution.ExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(ExecutableInvoker.java:115)
at
org.junit.jupiter.engine.execution.ExecutableInvoker.lambda$invoke$0(ExecutableInvoker.java:105)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:104)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:62)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:43)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:35)
at
org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:104)
at
org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(Exe
[jira] [Assigned] (CALCITE-4584) Using function in partition by list of over window cause converting exception
[
https://issues.apache.org/jira/browse/CALCITE-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin reassigned CALCITE-4584:
Assignee: Wang Yanlin
> Using function in partition by list of over window cause converting exception
> -
>
> Key: CALCITE-4584
> URL: https://issues.apache.org/jira/browse/CALCITE-4584
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When try to using function expr in the partition by list of over window in
> sql, got
> {noformat}
> java.lang.UnsupportedOperationException: class
> org.apache.calcite.sql.SqlBasicCall: CHAR_LENGTH(`ENAME`)
> {noformat}
> The stack trace is as follow
> {noformat}
> java.lang.RuntimeException: while converting CHAR_LENGTH(`EMP`.`ENAME`)
> at
> org.apache.calcite.sql2rel.ReflectiveConvertletTable.lambda$registerOpTypeMethod$3(ReflectiveConvertletTable.java:145)
> at
> org.apache.calcite.sql2rel.SqlNodeToRexConverterImpl.convertCall(SqlNodeToRexConverterImpl.java:62)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:5232)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:4486)
> at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:161)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:5088)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertOver(SqlToRelConverter.java:2037)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.access$2000(SqlToRelConverter.java:224)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:5081)
> at
> org.apache.calcite.sql2rel.StandardConvertletTable.lambda$new$9(StandardConvertletTable.java:209)
> at
> org.apache.calcite.sql2rel.SqlNodeToRexConverterImpl.convertCall(SqlNodeToRexConverterImpl.java:62)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:5232)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:4486)
> at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:161)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:5088)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectList(SqlToRelConverter.java:4327)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:707)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:664)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3538)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:589)
> at
> org.apache.calcite.test.SqlToRelTestBase$TesterImpl.convertSqlToRel(SqlToRelTestBase.java:638)
> at
> org.apache.calcite.test.SqlToRelTestBase$TesterImpl.assertConvertsTo(SqlToRelTestBase.java:799)
> at
> org.apache.calcite.test.SqlToRelConverterTest.testFunctionExprInOver(SqlToRelConverterTest.java:4196)
> 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.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:675)
> at
> org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:125)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:139)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:131)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:81)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(ExecutableInvoker.java:115)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker.lambda$invoke$0(ExecutableInvoker.java:105)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:104)
> at
> org.junit.jupiter.engine.execution.InvocationInter
[jira] [Commented] (CALCITE-4734) Materialization-Failed, when meeting same projs in mv.
[
https://issues.apache.org/jira/browse/CALCITE-4734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17407867#comment-17407867
]
Wang Yanlin commented on CALCITE-4734:
--
Fixed in
[https://github.com/apache/calcite/commit/4b4bb7ff3fd5ca4d2d3e7e8f9eab3df0cee49d76,]
thanks [~wojustme]
> Materialization-Failed, when meeting same projs in mv.
> --
>
> Key: CALCITE-4734
> URL: https://issues.apache.org/jira/browse/CALCITE-4734
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Xurenhe
>Priority: Critical
> Labels: pull-request-available
> Attachments: image-2021-08-13-11-43-54-035.png,
> image-2021-08-13-11-44-09-504.png
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Some user may define some not beautiful mv, but these mv should be worked for
> rewriting query.
> For example:
> {code:java}
> @Test void testMoreSameExprInMv() {
> final String mv = ""
> + "select \"empid\", \"deptno\", sum(\"empid\") as s1, sum(\"empid\")
> as s2, count(*) as c\n"
> + "from \"emps\" group by \"empid\", \"deptno\"";
> final String query = ""
> + "select sum(\"empid\"), count(*) from \"emps\" group by \"empid\",
> \"deptno\"";
> sql(mv, query).ok();
> }
> {code}
> I try debug code to solve this problem.
> I find some bug in
> {code:java}
> org.apache.calcite.plan.SubstitutionVisitor#getRexShuttle
> {code}
> !image-2021-08-13-11-43-54-035.png|thumbnail!
> !image-2021-08-13-11-44-09-504.png|thumbnail!
> PR: https://github.com/apache/calcite/pull/2484
> Please review, THX.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CALCITE-4734) Materialization-Failed, when meeting same projs in mv.
[
https://issues.apache.org/jira/browse/CALCITE-4734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin resolved CALCITE-4734.
--
Resolution: Fixed
> Materialization-Failed, when meeting same projs in mv.
> --
>
> Key: CALCITE-4734
> URL: https://issues.apache.org/jira/browse/CALCITE-4734
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Xurenhe
>Priority: Critical
> Labels: pull-request-available
> Attachments: image-2021-08-13-11-43-54-035.png,
> image-2021-08-13-11-44-09-504.png
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Some user may define some not beautiful mv, but these mv should be worked for
> rewriting query.
> For example:
> {code:java}
> @Test void testMoreSameExprInMv() {
> final String mv = ""
> + "select \"empid\", \"deptno\", sum(\"empid\") as s1, sum(\"empid\")
> as s2, count(*) as c\n"
> + "from \"emps\" group by \"empid\", \"deptno\"";
> final String query = ""
> + "select sum(\"empid\"), count(*) from \"emps\" group by \"empid\",
> \"deptno\"";
> sql(mv, query).ok();
> }
> {code}
> I try debug code to solve this problem.
> I find some bug in
> {code:java}
> org.apache.calcite.plan.SubstitutionVisitor#getRexShuttle
> {code}
> !image-2021-08-13-11-43-54-035.png|thumbnail!
> !image-2021-08-13-11-44-09-504.png|thumbnail!
> PR: https://github.com/apache/calcite/pull/2484
> Please review, THX.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CALCITE-4584) Using function in partition by list of over window cause converting exception
[
https://issues.apache.org/jira/browse/CALCITE-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin resolved CALCITE-4584.
--
Resolution: Fixed
> Using function in partition by list of over window cause converting exception
> -
>
> Key: CALCITE-4584
> URL: https://issues.apache.org/jira/browse/CALCITE-4584
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Major
> Labels: pull-request-available
> Time Spent: 50m
> Remaining Estimate: 0h
>
> When try to using function expr in the partition by list of over window in
> sql, got
> {noformat}
> java.lang.UnsupportedOperationException: class
> org.apache.calcite.sql.SqlBasicCall: CHAR_LENGTH(`ENAME`)
> {noformat}
> The stack trace is as follow
> {noformat}
> java.lang.RuntimeException: while converting CHAR_LENGTH(`EMP`.`ENAME`)
> at
> org.apache.calcite.sql2rel.ReflectiveConvertletTable.lambda$registerOpTypeMethod$3(ReflectiveConvertletTable.java:145)
> at
> org.apache.calcite.sql2rel.SqlNodeToRexConverterImpl.convertCall(SqlNodeToRexConverterImpl.java:62)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:5232)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:4486)
> at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:161)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:5088)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertOver(SqlToRelConverter.java:2037)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.access$2000(SqlToRelConverter.java:224)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:5081)
> at
> org.apache.calcite.sql2rel.StandardConvertletTable.lambda$new$9(StandardConvertletTable.java:209)
> at
> org.apache.calcite.sql2rel.SqlNodeToRexConverterImpl.convertCall(SqlNodeToRexConverterImpl.java:62)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:5232)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:4486)
> at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:161)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:5088)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectList(SqlToRelConverter.java:4327)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:707)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:664)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3538)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:589)
> at
> org.apache.calcite.test.SqlToRelTestBase$TesterImpl.convertSqlToRel(SqlToRelTestBase.java:638)
> at
> org.apache.calcite.test.SqlToRelTestBase$TesterImpl.assertConvertsTo(SqlToRelTestBase.java:799)
> at
> org.apache.calcite.test.SqlToRelConverterTest.testFunctionExprInOver(SqlToRelConverterTest.java:4196)
> 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.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:675)
> at
> org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:125)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:139)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:131)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:81)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(ExecutableInvoker.java:115)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker.lambda$invoke$0(ExecutableInvoker.java:105)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:104)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorCha
[jira] [Commented] (CALCITE-4584) Using function in partition by list of over window cause converting exception
[
https://issues.apache.org/jira/browse/CALCITE-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17409266#comment-17409266
]
Wang Yanlin commented on CALCITE-4584:
--
Fixed in
https://github.com/apache/calcite/commit/51c0d925489b57319502ffdebbdd93b6fe4e1e8a
> Using function in partition by list of over window cause converting exception
> -
>
> Key: CALCITE-4584
> URL: https://issues.apache.org/jira/browse/CALCITE-4584
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Major
> Labels: pull-request-available
> Time Spent: 50m
> Remaining Estimate: 0h
>
> When try to using function expr in the partition by list of over window in
> sql, got
> {noformat}
> java.lang.UnsupportedOperationException: class
> org.apache.calcite.sql.SqlBasicCall: CHAR_LENGTH(`ENAME`)
> {noformat}
> The stack trace is as follow
> {noformat}
> java.lang.RuntimeException: while converting CHAR_LENGTH(`EMP`.`ENAME`)
> at
> org.apache.calcite.sql2rel.ReflectiveConvertletTable.lambda$registerOpTypeMethod$3(ReflectiveConvertletTable.java:145)
> at
> org.apache.calcite.sql2rel.SqlNodeToRexConverterImpl.convertCall(SqlNodeToRexConverterImpl.java:62)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:5232)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:4486)
> at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:161)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:5088)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertOver(SqlToRelConverter.java:2037)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.access$2000(SqlToRelConverter.java:224)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:5081)
> at
> org.apache.calcite.sql2rel.StandardConvertletTable.lambda$new$9(StandardConvertletTable.java:209)
> at
> org.apache.calcite.sql2rel.SqlNodeToRexConverterImpl.convertCall(SqlNodeToRexConverterImpl.java:62)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:5232)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:4486)
> at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:161)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:5088)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectList(SqlToRelConverter.java:4327)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:707)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:664)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3538)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:589)
> at
> org.apache.calcite.test.SqlToRelTestBase$TesterImpl.convertSqlToRel(SqlToRelTestBase.java:638)
> at
> org.apache.calcite.test.SqlToRelTestBase$TesterImpl.assertConvertsTo(SqlToRelTestBase.java:799)
> at
> org.apache.calcite.test.SqlToRelConverterTest.testFunctionExprInOver(SqlToRelConverterTest.java:4196)
> 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.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:675)
> at
> org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:125)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:139)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:131)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:81)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(ExecutableInvoker.java:115)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker.lambda$invoke$0(ExecutableInvoker.java:105)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedIn
[jira] [Resolved] (CALCITE-3935) Materialization-Failed, meeting to pull up bottom filter of Left/Right Join
[
https://issues.apache.org/jira/browse/CALCITE-3935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin resolved CALCITE-3935.
--
Resolution: Fixed
Fixed in
[https://github.com/apache/calcite/commit/a36f5a21f006ee717e7949269a99fa48a65f6abe.]
thx [~wojustme]
> Materialization-Failed, meeting to pull up bottom filter of Left/Right Join
> ---
>
> Key: CALCITE-3935
> URL: https://issues.apache.org/jira/browse/CALCITE-3935
> Project: Calcite
> Issue Type: Bug
>Reporter: Xurenhe
>Assignee: Xurenhe
>Priority: Major
> Labels: pull-request-available
> Attachments: Jietu20200417-200532.png
>
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> Hi all.
> `SubstitutionVisitor` support more join_type in some rules of `Join`.
> Now `SubstitutionVisitor` only support join type of `INNER`, when pulling up
> bottom filters of join.
> It doesn't work as follows.
> {code:java}
> @Test public void testJoinOnLeftProjectWithFilterToJoin() {
> String mv = ""
> + "select \"emps\".\"empid\", \"depts\".\"name\",
> \"emps\".\"salary\"\n" +
> "from \"emps\"\n" +
> "left join \"depts\"\n" +
> "on \"emps\".\"deptno\" = \"depts\".\"deptno\"\n"
> + "where \"emps\".\"empid\" > 10";
> String query = ""
> + "select \"emps\".\"empid\", \"depts\".\"name\",
> \"emps\".\"salary\"\n" +
> "from \"emps\"\n" +
> "left join \"depts\"\n" +
> "on \"emps\".\"deptno\" = \"depts\".\"deptno\"\n"
> + "where \"emps\".\"empid\" > 40";
> sql(mv, query).withOnlyBySubstitution(true).ok();
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CALCITE-4779) GroupByList contains constant literal, materialized view recognition failed
[
https://issues.apache.org/jira/browse/CALCITE-4779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin resolved CALCITE-4779.
--
Resolution: Fixed
Fixed in
[https://github.com/apache/calcite/commit/219e41eab20533f02d41238d1ebc617cc813b9a2,]
thx [~xzh_dz]
> GroupByList contains constant literal, materialized view recognition failed
> ---
>
> Key: CALCITE-4779
> URL: https://issues.apache.org/jira/browse/CALCITE-4779
> Project: Calcite
> Issue Type: Improvement
>Reporter: xzh_dz
>Priority: Major
> Labels: pull-request-available
> Attachments: image-2021-09-19-06-41-52-352.png
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> {code:java}
> // code placeholder
> org.apache.calcite.test.MaterializedViewSubstitutionVisitorTest
> @Test void testCountDistinct() {
> final String mv = ""
> + "select \"deptno\", \"empid\"\n"
> + "from \"emps\"\n"
> + "group by \"deptno\", \"empid\"";
> final String query = ""
> + "select 1, \"deptno\"\n"
> + "from \"emps\"\n"
> + "group by 1, \"deptno\"";
> sql(mv, query).ok();
> }
> {code}
> Materialized view failed to be matched by optimized results:Materialized view
> failed to be matched by optimized results: java.lang.AssertionError:
> Materialized view failed to be matched by optimized results: at
> org.apache.calcite.test.AbstractMaterializedViewTest.checkMaterialize(AbstractMaterializedViewTest.java:116)
> at
> org.apache.calcite.test.AbstractMaterializedViewTest.access$000(AbstractMaterializedViewTest.java:67)
> at
> org.apache.calcite.test.AbstractMaterializedViewTest$Sql.ok(AbstractMaterializedViewTest.java:229)
> at java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:627)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CALCITE-4778) Exchange operator deserialize fail when the RexInput has no RelCollcation
[
https://issues.apache.org/jira/browse/CALCITE-4778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin resolved CALCITE-4778.
--
Resolution: Fixed
Fixed in
[https://github.com/apache/calcite/commit/2916b83712b517430e71c1c22042e484ee900589,]
thx [~xzh_dz]
> Exchange operator deserialize fail when the RexInput has no RelCollcation
> -
>
> Key: CALCITE-4778
> URL: https://issues.apache.org/jira/browse/CALCITE-4778
> Project: Calcite
> Issue Type: Improvement
>Reporter: xzh_dz
>Priority: Major
> Labels: pull-request-available
> Time Spent: 1h
> Remaining Estimate: 0h
>
> {code:java}
> // code placeholder
> org.apache.calcite.plan.RelWriterTest
> @Test public void testExchange() {
> final FrameworkConfig config = RelBuilderTest.config().build();
> final RelBuilder builder = RelBuilder.create(config);
> final RelNode rel = builder
> .scan("EMP")
> .exchange(RelDistributions.hash(ImmutableList.of(0, 1)))
> .build();
> final String relJson = RelOptUtil.dumpPlan("", rel,
> SqlExplainFormat.JSON, SqlExplainLevel.EXPPLAN_ATTRIBUTES);
> String s = deserializeAndDumpToTextFormat(getSchema(rel), relJson);
> final String expected = ""
> + "LogicalExchange(distribution=[hash[0, 1]])\n"
> + " LogicalTableScan(table=[[scott, EMP]])\n";
> assertThat(s, isLinux(expected));
> }
> {code}
> java.lang.NullPointerException: no entry for tag
> collationjava.lang.NullPointerException: no entry for tag
> collationjava.lang.RuntimeException: java.lang.NullPointerException: no entry
> for tag collation at
> org.apache.calcite.tools.Frameworks.withPrepare(Frameworks.java:193) at
> org.apache.calcite.tools.Frameworks.withPlanner(Frameworks.java:135) at
> org.apache.calcite.tools.Frameworks.withPlanner(Frameworks.java:153)
> Caused by: java.lang.NullPointerException: no entry for tag collationCaused
> by: java.lang.NullPointerException: no entry for tag collation at
> java.util.Objects.requireNonNull(Objects.java:290) at
> org.apache.calcite.rel.externalize.RelJsonReader$2.getNonNull(RelJsonReader.java:202)
> at
> org.apache.calcite.rel.externalize.RelJsonReader$2.getCollation(RelJsonReader.java:260)
> at org.apache.calcite.rel.core.Exchange.(Exchange.java:73) at
> org.apache.calcite.rel.logical.LogicalExchange.(LogicalExchange.java:44)
> 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:289)
> at
> org.apache.calcite.rel.externalize.RelJsonReader.readRels(RelJsonReader.java:107)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (CALCITE-3583) Support serialized to json and deserialized from json for Exchange relation operator
[
https://issues.apache.org/jira/browse/CALCITE-3583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin closed CALCITE-3583.
Resolution: Duplicate
Duplicate with https://issues.apache.org/jira/browse/CALCITE-4778, close this
one.
> Support serialized to json and deserialized from json for Exchange relation
> operator
>
>
> Key: CALCITE-3583
> URL: https://issues.apache.org/jira/browse/CALCITE-3583
> Project: Calcite
> Issue Type: Improvement
>Reporter: Wang Yanlin
>Priority: Major
> Labels: pull-request-available
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> Currently, serialize Exchange relnode to json will cause exception
> {code:java}
> // RelWriterTest
> @Test public void testExchange() {
> final FrameworkConfig config = RelBuilderTest.config().build();
> final RelBuilder builder = RelBuilder.create(config);
> final RelNode rel = builder
> .scan("EMP")
> .exchange(RelDistributions.hash(ImmutableList.of(0, 1)))
> .build();
> String relJson = RelOptUtil.dumpPlan("", rel,
> SqlExplainFormat.JSON, SqlExplainLevel.EXPPLAN_ATTRIBUTES);
> String s = deserializeAndDumpToTextFormat(getSchema(rel), relJson);
> final String expected = ""
> + "LogicalExchange(distribution=[hash[0, 1]])\n"
> + " LogicalTableScan(table=[[scott, EMP]])\n";
> assertThat(s, isLinux(expected));
> }
> {code}
> got
> {code:java}
> java.lang.UnsupportedOperationException: type not serializable: hash[0, 1]
> (type org.apache.calcite.rel.RelDistributions.RelDistributionImpl)
> at org.apache.calcite.rel.externalize.RelJson.toJson(RelJson.java:290)
> at
> org.apache.calcite.rel.externalize.RelJsonWriter.put(RelJsonWriter.java:83)
> at
> org.apache.calcite.rel.externalize.RelJsonWriter.explain_(RelJsonWriter.java:66)
> at
> org.apache.calcite.rel.externalize.RelJsonWriter.done(RelJsonWriter.java:128)
> at
> org.apache.calcite.rel.AbstractRelNode.explain(AbstractRelNode.java:299)
> at org.apache.calcite.plan.RelOptUtil.dumpPlan(RelOptUtil.java:1981)
> at
> org.apache.calcite.plan.RelWriterTest.testExchange(RelWriterTest.java:772)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CALCITE-4735) SubstitutionVisitor of Aggregate Failed, when aggcalls of query could be expressed by target's grouping
[
https://issues.apache.org/jira/browse/CALCITE-4735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin resolved CALCITE-4735.
--
Resolution: Fixed
Fixed in
[https://github.com/apache/calcite/commit/46fb2632ea4457e5c0f87d42536ae2d5cdf5f07d,]
thx [~wojustme]
> SubstitutionVisitor of Aggregate Failed, when aggcalls of query could be
> expressed by target's grouping
> ---
>
> Key: CALCITE-4735
> URL: https://issues.apache.org/jira/browse/CALCITE-4735
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Xurenhe
>Assignee: Xurenhe
>Priority: Major
> Labels: pull-request-available
> Time Spent: 6h 40m
> Remaining Estimate: 0h
>
> `SubstitutionVisitor` don't work for rewriting query by mv, let me show a
> example of the current failure.
> {code:java}
> @Test void testAggCallArgExpressedByMvProjs() {
> final String mv = ""
> + "select \"deptno\", \"name\""
> + "from \"emps\" group by \"deptno\", \"name\"";
> final String query = ""
> + "select \"deptno\", \"name\", count(distinct \"name\")"
> + "from \"emps\" group by \"deptno\", \"name\"";
> sql(mv, query).ok();
> }
> {code}
> I debug this issue, I found that: when `AggregateToAggregateUnifyRule`
> executing `unifyAggregates`, code want to find agg-calls of query could be
> equal or rollup by target's agg-calls.
> Should we have other way to handle in `AggregateToAggregateUnifyRule` or
> `AggregateOnCalcToAggregateUnifyRule`?
> I will give some examples to explain the problem:
> {code:sql}
> -- schema
> create table emps (
> empid integer,
> deptno integer,
> name varchar,
> salary float,
> commission integer
> )
> {code}
>
> AggregateToAggregateUnifyRule
> case1: mv's group equal to query's group
> {code:sql}
> --mv
> select deptno, commission
> from emps
> group by deptno, commission
> --query
> select deptno, commission, count(1), count(distinct commission)
> from emps
> group by deptno, commission
> --rewrite
> select deptno, commission, count(1), count(distinct commission)
> from mv
> group by deptno, commission
> {code}
> case2: mv's group rollup to query's group
> {code:sql}
> --mv
> select deptno, commission
> from emps
> group by deptno, commission
> --query
> select deptno, max(commission)
> from emps
> group by deptno
> --rewrite
> select deptno, max(commission)
> from mv
> group by deptno
> {code}
>
> AggregateOnCalcToAggregateUnifyRule
> case1: mv's group equal to query's group
> {code:sql}
> --mv
> select deptno, commission, mix(salary)
> from emps
> group by deptno, commission
> --query
> select deptno, commission, count(1)
> from emps
> group by deptno, commission
> --rewrite
> select deptno, commission, count(1)
> from mv
> group by deptno, commission
> {code}
> case2: mv's group rollup to query's group
> {code:sql}
> --mv
> select deptno, commission, name, mix(salary)
> from emps
> group by deptno, commission, name
> --query
> select deptno, commission, count(1), count(distinct name)
> from emps
> group by deptno, commission
> --rewrite
> select deptno, commission, count(1), count(distinct name)
> from mv
> group by deptno, commission
> {code}
>
> Here, Should we create new agg-calls to compensate missing agg-calls of
> query, which is based on mv's agg-group?
> Rewriting query's agg-call could be rewritten by equal agg-call of mv or
> rollup agg-call of mv,
> also could be {color:#ff}rewritten by emitted agg-group of mv{color}.
> Please review this viewpoint, if this viewpoint is right, I can do it.
> Thanks a lot.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4857) Materialization-Failed, query could be grouping mv's agg-call, when executing mv-match.
[
https://issues.apache.org/jira/browse/CALCITE-4857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17430279#comment-17430279
]
Wang Yanlin commented on CALCITE-4857:
--
How about simplify
{noformat}
select deptno, salary, max(salary), min(commission)
from emps
group by deptno, salary
{noformat}
to
{noformat}
select deptno, salary, salary as expr, min(commission)
from emps
group by deptno, salary
{noformat}
Then, the query can be matched.
> Materialization-Failed, query could be grouping mv's agg-call, when executing
> mv-match.
> ---
>
> Key: CALCITE-4857
> URL: https://issues.apache.org/jira/browse/CALCITE-4857
> Project: Calcite
> Issue Type: Bug
>Reporter: Xurenhe
>Priority: Major
> Attachments: image-2021-10-18-11-18-02-312.png
>
>
> Here, query could be rewritten by mv, but it's failed now.
> {code:java}
> -- mv:
> select deptno, salary, min(commission) as commission_min
> from emps
> group by deptno, salary
> -- query:
> select deptno, salary, max(salary), min(commission)
> from emps
> group by deptno, salary
> -- after mv match
> select deptno, salary, max(salary), commission_min
> from mv
> group by deptno, salary, commission_min
> {code}
>
> !image-2021-10-18-11-18-02-312.png!
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3254) AssertionError while deserializing of interval type.
[
https://issues.apache.org/jira/browse/CALCITE-3254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin updated CALCITE-3254:
-
Description:
case 1:
When deserializing of logical rel haveing interval type, AssertionError occurs.
The exception stacktrace as follow:
{code:java}
java.lang.RuntimeException: java.lang.RuntimeException:
java.lang.AssertionError: use createSqlIntervalType() instead
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.testInterval(RelWriterTest.java:639)
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.RuntimeException: java.lang.AssertionError: use
createSqlIntervalType() instead
at
org.apache.calcite.rel.externalize.RelJsonReader.readRel(RelJsonReader.java:271)
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$testInterval$8(RelWriterTest.java:644)
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
Caused by: java.lang.AssertionError: use createSqlIntervalType() instead
at
org.apache.calcite.sql.type.SqlTypeFactoryImpl.assertBasic(SqlTypeFactoryImpl.java:222)
at
org.apache.calcite.sql.type.SqlTypeFactoryImpl.createSqlType(SqlTypeFactoryImpl.java:75)
at org.apache.calcite.rel.externalize.RelJson.toType(RelJson.java:222)
at org.apache.calcite.rel.externalize.RelJson.toRex(RelJson.java:516)
at
org.apache.calcite.rel.externalize.RelJson.toRexList(RelJson.java:607)
at org.apache.calcite.rel.externalize.RelJson.toRex(RelJson.java:447)
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)
... 31 more
{code}
case 2:
when deserializing for RexOver with empty parititon key or order key,
NullPointerException occurs, like this
{code:java}
java.lang.RuntimeException: java.lang.NullPointerException
at org.apache.calcite.tools.Fr
[jira] [Updated] (CALCITE-3254) Exception while deserializing of interval type or with empty partition key for RexOver.
[
https://issues.apache.org/jira/browse/CALCITE-3254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin updated CALCITE-3254:
-
Summary: Exception while deserializing of interval type or with empty
partition key for RexOver. (was: AssertionError while deserializing of
interval type.)
> Exception while deserializing of interval type or with empty partition key
> for RexOver.
> ---
>
> Key: CALCITE-3254
> URL: https://issues.apache.org/jira/browse/CALCITE-3254
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Priority: Major
> Labels: pull-request-available
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> case 1:
> When deserializing of logical rel haveing interval type, AssertionError
> occurs.
> The exception stacktrace as follow:
> {code:java}
> java.lang.RuntimeException: java.lang.RuntimeException:
> java.lang.AssertionError: use createSqlIntervalType() instead
> 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.testInterval(RelWriterTest.java:639)
> 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.RuntimeException: java.lang.AssertionError: use
> createSqlIntervalType() instead
> at
> org.apache.calcite.rel.externalize.RelJsonReader.readRel(RelJsonReader.java:271)
> 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$testInterval$8(RelWriterTest.java:644)
> 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
> Caused by: java.lang.AssertionError: use createSqlIntervalType() instead
> at
> org.apache.calcite.sql.type.SqlTypeFactoryImpl.assertBasic(SqlTypeFactoryImpl.java:222)
> at
> org.apache.calcite.sql.type.SqlTypeFactoryImpl.createSqlType(SqlTypeFactoryImpl.java:75)
> at org.apache.calcite.rel.externalize.RelJson.toType(RelJson.java:222)
> at org.apache.calcite.rel.externalize.RelJson.toRex(RelJson.java:516)
> at
> org.apache.calcite.rel.externalize.RelJson.toRexList(RelJson.java:607)
> at org.apache.calcite.rel.externalize.RelJson.toRex(RelJson.java:447)
> 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.j
[jira] [Commented] (CALCITE-3319) AssertionError for ReduceDecimalsRule
[
https://issues.apache.org/jira/browse/CALCITE-3319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16923158#comment-16923158
]
Wang Yanlin commented on CALCITE-3319:
--
OK.
> AssertionError for ReduceDecimalsRule
> -
>
> Key: CALCITE-3319
> URL: https://issues.apache.org/jira/browse/CALCITE-3319
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When trying to use *ReduceDecimalsRule*, I got
> {code:java}
> java.lang.AssertionError
> at
> org.apache.calcite.rel.rules.ReduceDecimalsRule$DecimalShuttle.visitCall(ReduceDecimalsRule.java:159)
> at
> org.apache.calcite.rel.rules.ReduceDecimalsRule$DecimalShuttle.visitCall(ReduceDecimalsRule.java:124)
> at org.apache.calcite.rex.RexCall.accept(RexCall.java:191)
> at
> org.apache.calcite.rex.RexProgramBuilder.add(RexProgramBuilder.java:653)
> at
> org.apache.calcite.rex.RexProgramBuilder.create(RexProgramBuilder.java:601)
> at
> org.apache.calcite.rel.rules.ReduceDecimalsRule.onMatch(ReduceDecimalsRule.java:103)
> at
> org.apache.calcite.plan.AbstractRelOptPlanner.fireRule(AbstractRelOptPlanner.java:319)
> at org.apache.calcite.plan.hep.HepPlanner.applyRule(HepPlanner.java:560)
> at
> org.apache.calcite.plan.hep.HepPlanner.applyRules(HepPlanner.java:419)
> at
> org.apache.calcite.plan.hep.HepPlanner.executeInstruction(HepPlanner.java:256)
> at
> org.apache.calcite.plan.hep.HepInstruction$RuleInstance.execute(HepInstruction.java:127)
> at
> org.apache.calcite.plan.hep.HepPlanner.executeProgram(HepPlanner.java:215)
> at
> org.apache.calcite.plan.hep.HepPlanner.findBestExp(HepPlanner.java:202)
> {code}
> I read the code, and found this.
> {code:java}
> List newOperands = apply(call.getOperands());
> if (true) {
> // FIXME: Operands are now immutable. Create a new call with
> // new operands?
> throw new AssertionError();
> }
> {code}
> After remove this logic, the rel below
> {code:java}
> LogicalCalc(expr#0..7=[{inputs}], expr#8=[1.01E1:DOUBLE], expr#9=[15],
> expr#10=[+($t8, $t9)], expr#11=[>($t5, $t10)], proj#0..7=[{exprs}],
> $condition=[$t11])
> LogicalTableScan(table=[[scott, EMP]])
> {code}
> can be translated into
> {code:java}
> LogicalCalc(expr#0..7=[{inputs}], expr#8=[Reinterpret($t5)],
> expr#9=[CAST($t8):DOUBLE], expr#10=[1E2:DOUBLE], expr#11=[/INT($t9, $t10)],
> expr#12=[1.01E1:DOUBLE], expr#13=[15], expr#14=[+($t12, $t13)],
> expr#15=[>($t11, $t14)], proj#0..7=[{exprs}], $condition=[$t15])
> LogicalTableScan(table=[[scott, EMP]])
> {code}
> So is this rule not ready for use now, or we should just remove this logic?
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (CALCITE-3313) AssertionError for using an invalid type parameter in REGEXP_REPLACE
[
https://issues.apache.org/jira/browse/CALCITE-3313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16923172#comment-16923172
]
Wang Yanlin commented on CALCITE-3313:
--
oh, my bad. I will update the PR, override the getOperandTypeChecker method.
> AssertionError for using an invalid type parameter in REGEXP_REPLACE
>
>
> Key: CALCITE-3313
> URL: https://issues.apache.org/jira/browse/CALCITE-3313
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Priority: Minor
> Labels: pull-request-available
> Time Spent: 2h
> Remaining Estimate: 0h
>
> When using REGEXP_REPLACE function with an invalid type parameter, like this
> {code:sql}
> select regexp_replace(12, 'b', 'X', 1, 3, 'i')
> {code}
> we got
> {code:java}
> java.lang.AssertionError: If you see this, assign operandTypeChecker a value
> or override this function
> at
> org.apache.calcite.sql.SqlOperator.getAllowedSignatures(SqlOperator.java:730)
> at
> org.apache.calcite.sql.SqlOperator.getAllowedSignatures(SqlOperator.java:721)
> at
> org.apache.calcite.sql.SqlCallBinding.newValidationSignatureError(SqlCallBinding.java:283)
> at
> org.apache.calcite.sql.type.FamilyOperandTypeChecker.checkSingleOperandType(FamilyOperandTypeChecker.java:96)
> at
> org.apache.calcite.sql.fun.SqlRegexpReplaceFunction.checkOperandTypes(SqlRegexpReplaceFunction.java:56)
> at
> org.apache.calcite.sql.SqlOperator.validateOperands(SqlOperator.java:432)
> at org.apache.calcite.sql.SqlFunction.deriveType(SqlFunction.java:298)
> at org.apache.calcite.sql.SqlFunction.deriveType(SqlFunction.java:216)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5626)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5613)
> at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:139)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.deriveTypeImpl(SqlValidatorImpl.java:1688)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.deriveType(SqlValidatorImpl.java:1673)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.expandSelectItem(SqlValidatorImpl.java:476)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelectList(SqlValidatorImpl.java:4104)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3392)
> at
> org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:60)
> at
> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:1005)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:965)
> at org.apache.calcite.sql.SqlSelect.validate(SqlSelect.java:216)
> {code}
> Better to give a more detailed message of the allowed signatures.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Created] (CALCITE-3346) able some ignored tests in RelOptRuleTests
Wang Yanlin created CALCITE-3346: Summary: able some ignored tests in RelOptRuleTests Key: CALCITE-3346 URL: https://issues.apache.org/jira/browse/CALCITE-3346 Project: Calcite Issue Type: Improvement Reporter: Wang Yanlin When reading the code, i found that some ignored test case in *RelOptRulesTest* actually can pass the test. Maybe we should try to enable these tests. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (CALCITE-3346) Enable some ignored tests in RelOptRuleTests
[ https://issues.apache.org/jira/browse/CALCITE-3346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wang Yanlin updated CALCITE-3346: - Summary: Enable some ignored tests in RelOptRuleTests (was: able some ignored tests in RelOptRuleTests) > Enable some ignored tests in RelOptRuleTests > > > Key: CALCITE-3346 > URL: https://issues.apache.org/jira/browse/CALCITE-3346 > Project: Calcite > Issue Type: Improvement >Reporter: Wang Yanlin >Priority: Minor > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > When reading the code, i found that some ignored test case in > *RelOptRulesTest* actually can pass the test. Maybe we should try to enable > these tests. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (CALCITE-3348) AssertionError while determining distribution of Calc
Wang Yanlin created CALCITE-3348:
Summary: AssertionError while determining distribution of Calc
Key: CALCITE-3348
URL: https://issues.apache.org/jira/browse/CALCITE-3348
Project: Calcite
Issue Type: Improvement
Components: core
Reporter: Wang Yanlin
When using *EnumerableCalcRule* with *RelDistributionTraitDef* for planner, got
{code:java}
java.lang.AssertionError
at
org.apache.calcite.rel.metadata.RelMdDistribution.calc(RelMdDistribution.java:144)
at
org.apache.calcite.rel.logical.LogicalCalc.lambda$create$1(LogicalCalc.java:108)
at org.apache.calcite.plan.RelTraitSet.replaceIf(RelTraitSet.java:249)
at
org.apache.calcite.rel.logical.LogicalCalc.create(LogicalCalc.java:107)
at
org.apache.calcite.rel.rules.FilterToCalcRule.onMatch(FilterToCalcRule.java:77)
at
org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:208)
at
org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:631)
at
org.apache.calcite.tools.Programs$RuleSetProgram.run(Programs.java:327)
at
org.apache.calcite.test.RelOptRulesTest.testEnumerableCalcRule(RelOptRulesTest.java:6346)
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}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (CALCITE-3348) AssertionError while determining distribution of Calc
[
https://issues.apache.org/jira/browse/CALCITE-3348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin updated CALCITE-3348:
-
Issue Type: Bug (was: Improvement)
> AssertionError while determining distribution of Calc
> -
>
> Key: CALCITE-3348
> URL: https://issues.apache.org/jira/browse/CALCITE-3348
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Wang Yanlin
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When using *EnumerableCalcRule* with *RelDistributionTraitDef* for planner,
> got
> {code:java}
> java.lang.AssertionError
> at
> org.apache.calcite.rel.metadata.RelMdDistribution.calc(RelMdDistribution.java:144)
> at
> org.apache.calcite.rel.logical.LogicalCalc.lambda$create$1(LogicalCalc.java:108)
> at org.apache.calcite.plan.RelTraitSet.replaceIf(RelTraitSet.java:249)
> at
> org.apache.calcite.rel.logical.LogicalCalc.create(LogicalCalc.java:107)
> at
> org.apache.calcite.rel.rules.FilterToCalcRule.onMatch(FilterToCalcRule.java:77)
> at
> org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:208)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:631)
> at
> org.apache.calcite.tools.Programs$RuleSetProgram.run(Programs.java:327)
> at
> org.apache.calcite.test.RelOptRulesTest.testEnumerableCalcRule(RelOptRulesTest.java:6346)
> 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}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (CALCITE-3347) IndexOutOfBoundsException in FixNullabilityShuttle when using FilterIntoJoinRule
[
https://issues.apache.org/jira/browse/CALCITE-3347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16930306#comment-16930306
]
Wang Yanlin commented on CALCITE-3347:
--
In the original case of "TestCalcite.java", when *FilterIntoJoinRule* matched
with
{code:none}
EnumerableFilter.ENUMERABLE.[](input=RelSubset#38,condition==($1, 0))
{code}
and
{code:none}
EnumerableHashJoin.ENUMERABLE.[](left=RelSubset#17,right=RelSubset#73,condition==($0,
$3),joinType=semi)
{code}
The dumped plan is like this
{noformat}
EnumerableFilter.ENUMERABLE.[](input=RelSubset#38,condition==($1, 0))
EnumerableHashJoin.ENUMERABLE.[](left=RelSubset#17,right=RelSubset#73,condition==($0,
$3),joinType=semi)
EnumerableTableScan(subset=[rel#17:Subset#0.ENUMERABLE.[]],
table=[[tblspace1, tsql]])
LogicalAggregate(subset=[rel#23:Subset#3.NONE.[]], group=[{0}])
LogicalProject(subset=[rel#21:Subset#2.NONE.[]], K1=[$0])
LogicalFilter(subset=[rel#19:Subset#1.NONE.[]], condition=[=($1, 1)])
EnumerableTableScan(subset=[rel#17:Subset#0.ENUMERABLE.[]],
table=[[tblspace1, tsql]])
{noformat}
The rowType of join is
{noformat}
RecordType(VARCHAR NOT NULL k1, INTEGER NOT NULL n1, VARCHAR NOT NULL s1) NOT
NULL
{noformat}
In this case, *FilterIntoJoinRule* tries to push filter condition *==($1, 0)*
into filter's left,
and push join condition *==($0, $3)* above join.
But the rowType of join has only 3 fields, causing the exception.
I think the cause is in here [call of
validateJoinFilters|https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/rel/rules/FilterJoinRule.java#L183].
Trying to push filter condition *==($0, $3)* above EnumerableHashJoin, but
actually should not.
> IndexOutOfBoundsException in FixNullabilityShuttle when using
> FilterIntoJoinRule
>
>
> Key: CALCITE-3347
> URL: https://issues.apache.org/jira/browse/CALCITE-3347
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.21.0
>Reporter: Amit Chavan
>Priority: Major
> Attachments: TestCalcite.java
>
>
> I am reporting a bug that happens in calcite 1.21 release. I have a query as
> below
> String query = "SELECT * FROM tblspace1.tsql where n1=? and k1 in (SELECT k1
> FROM tblspace1.tsql where n1=?)";
>
> I am also attaching the unit test to reproduce this issue.
>
> The filterJoinRule throws an exception –
> java.lang.RuntimeException: Error while applying rule
> FilterJoinRule:FilterJoinRule:filter, args
> [rel#39:EnumerableFilter.ENUMERABLE.[](input=RelSubset#38,condition==($1,
> ?0)),
> rel#176:EnumerableHashJoin.ENUMERABLE.[](left=RelSubset#17,right=RelSubset#73,condition==($0,
> $3),joinType=semi)]
> at
> org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:235)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:631)
> at org.apache.calcite.TestCalcite.testQuery(TestCalcite.java:199)
> at org.apache.calcite.TestCalcite.problem_with_1_21(TestCalcite.java:256)
> 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:497)
> 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.J
[jira] [Commented] (CALCITE-3347) IndexOutOfBoundsException in FixNullabilityShuttle when using FilterIntoJoinRule
[ https://issues.apache.org/jira/browse/CALCITE-3347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16930348#comment-16930348 ] Wang Yanlin commented on CALCITE-3347: -- I add a [getAllInputRef|https://github.com/yanlin-Lynn/calcite/blob/filter-join-rule/core/src/main/java/org/apache/calcite/rex/RexUtil.java#L2084] in RexUtil, and use it to [filter|https://github.com/yanlin-Lynn/calcite/blob/filter-join-rule/core/src/main/java/org/apache/calcite/rel/rules/FilterJoinRule.java#L340] cases not suitable to push filter condition above, and it works for the test case. Not sure is this a good way to fix. > IndexOutOfBoundsException in FixNullabilityShuttle when using > FilterIntoJoinRule > > > Key: CALCITE-3347 > URL: https://issues.apache.org/jira/browse/CALCITE-3347 > Project: Calcite > Issue Type: Bug >Affects Versions: 1.21.0 >Reporter: Amit Chavan >Priority: Major > Attachments: TestCalcite.java > > > I am reporting a bug that happens in calcite 1.21 release. I have a query as > below > String query = "SELECT * FROM tblspace1.tsql where n1=? and k1 in (SELECT k1 > FROM tblspace1.tsql where n1=?)"; > > I am also attaching the unit test to reproduce this issue. > > The filterJoinRule throws an exception – > java.lang.RuntimeException: Error while applying rule > FilterJoinRule:FilterJoinRule:filter, args > [rel#39:EnumerableFilter.ENUMERABLE.[](input=RelSubset#38,condition==($1, > ?0)), > rel#176:EnumerableHashJoin.ENUMERABLE.[](left=RelSubset#17,right=RelSubset#73,condition==($0, > $3),joinType=semi)] > at > org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:235) > at > org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:631) > at org.apache.calcite.TestCalcite.testQuery(TestCalcite.java:199) > at org.apache.calcite.TestCalcite.problem_with_1_21(TestCalcite.java:256) > 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:497) > 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.IndexOutOfBoundsException: index (3) must be less than > size (3) > at > com.google.common.base.Preconditions.checkElementIndex(Preconditions.java:310) > at > com.google.common.base.Preconditions.checkElementIndex(Preconditions.java:293) > at > com.google.common.collect.RegularImmutableList.get(RegularImmutableList.java:67) > at > com.google.common.collect.Lists$TransformingRandomAccessList.get(Lists.java:627) > at > org.apache.calcite.rex.RexUtil$FixNullabilityShuttle.visitInputRef(RexUtil.java:2529) > at > org.apache.calcite.rex.RexUtil$FixNullabilityShuttle.visitInputRef(RexUtil.java:2518) > at org.apache.calcite.rex.RexInputRef.accept(RexInputRef.java:112) > at org.apache.calcite.rex.RexShuttle.visitList(RexShuttle.java:149) > at org.apache.calcite.rex.RexShuttle.visitCall(RexShuttle.java:101) > at org.apache.calcite.rex.RexShuttle.visitCall(RexShuttle.java:34) > at org.apache.calcite.rex.RexCall.accept(RexCall.java:191) > at org.apache.calcite.rex.RexShuttle.apply(RexShuttle.java:277) > at org.apache.calcite.rex.Rex
[jira] [Comment Edited] (CALCITE-3347) IndexOutOfBoundsException in FixNullabilityShuttle when using FilterIntoJoinRule
[ https://issues.apache.org/jira/browse/CALCITE-3347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16930348#comment-16930348 ] Wang Yanlin edited comment on CALCITE-3347 at 9/16/19 9:27 AM: --- I add a [getAllInputRef|https://github.com/yanlin-Lynn/calcite/blob/filter-join-rule/core/src/main/java/org/apache/calcite/rex/RexUtil.java#L2084] in RexUtil, and use it to [filter|https://github.com/yanlin-Lynn/calcite/blob/filter-join-rule/core/src/main/java/org/apache/calcite/rel/rules/FilterJoinRule.java#L340] cases not suitable to push filter condition above, and it works for the test case. This works for the test case. Not sure is this a good way to fix. was (Author: yanlin-lynn): I add a [getAllInputRef|https://github.com/yanlin-Lynn/calcite/blob/filter-join-rule/core/src/main/java/org/apache/calcite/rex/RexUtil.java#L2084] in RexUtil, and use it to [filter|https://github.com/yanlin-Lynn/calcite/blob/filter-join-rule/core/src/main/java/org/apache/calcite/rel/rules/FilterJoinRule.java#L340] cases not suitable to push filter condition above, and it works for the test case. Not sure is this a good way to fix. > IndexOutOfBoundsException in FixNullabilityShuttle when using > FilterIntoJoinRule > > > Key: CALCITE-3347 > URL: https://issues.apache.org/jira/browse/CALCITE-3347 > Project: Calcite > Issue Type: Bug >Affects Versions: 1.21.0 >Reporter: Amit Chavan >Priority: Major > Attachments: TestCalcite.java > > > I am reporting a bug that happens in calcite 1.21 release. I have a query as > below > String query = "SELECT * FROM tblspace1.tsql where n1=? and k1 in (SELECT k1 > FROM tblspace1.tsql where n1=?)"; > > I am also attaching the unit test to reproduce this issue. > > The filterJoinRule throws an exception – > java.lang.RuntimeException: Error while applying rule > FilterJoinRule:FilterJoinRule:filter, args > [rel#39:EnumerableFilter.ENUMERABLE.[](input=RelSubset#38,condition==($1, > ?0)), > rel#176:EnumerableHashJoin.ENUMERABLE.[](left=RelSubset#17,right=RelSubset#73,condition==($0, > $3),joinType=semi)] > at > org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:235) > at > org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:631) > at org.apache.calcite.TestCalcite.testQuery(TestCalcite.java:199) > at org.apache.calcite.TestCalcite.problem_with_1_21(TestCalcite.java:256) > 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:497) > 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.IndexOutOfBoundsException: index (3) must be less than > size (3) > at > com.google.common.base.Preconditions.checkElementIndex(Preconditions.java:310) > at > com.google.common.base.Preconditions.checkElementIndex(Preconditions.java:293) > at > com.google.common.collect.RegularImmutableList.get(RegularImmutableList.java:67) > at > com.google.common.collect.Lists$TransformingRandomAccessList.get(Lists.java:627) > at > org.apache.calcite.rex.RexUtil$FixNullabilityShuttle.visitInputRef(RexUtil.
[jira] [Created] (CALCITE-3350) Keep origin type for RexLiteral when deserialized from json string
Wang Yanlin created CALCITE-3350:
Summary: Keep origin type for RexLiteral when deserialized from
json string
Key: CALCITE-3350
URL: https://issues.apache.org/jira/browse/CALCITE-3350
Project: Calcite
Issue Type: Improvement
Reporter: Wang Yanlin
The json string of sql
{noformat}
select ename from emp where job = "abd"
{noformat}
is
{noformat}
{
"rels": [
{
"id": "0",
"relOp": "LogicalTableScan",
"table": [
"scott",
"EMP"
],
"inputs": []
},
{
"id": "1",
"relOp": "LogicalFilter",
"condition": {
"op": {
"name": "=",
"kind": "EQUALS",
"syntax": "BINARY"
},
"operands": [
{
"input": 2,
"name": "$2"
},
{
"literal": "abd",
"type": {
"type": "VARCHAR",
"nullable": false,
"precision": 10
}
}
]
}
},
{
"id": "2",
"relOp": "LogicalProject",
"fields": [
"ENAME"
],
"exprs": [
{
"input": 1,
"name": "$1"
}
]
}
]
}
{noformat}
The original type of literal "abd" is
{noformat}
VARCHAR(10) NOT NULL
{noformat}
When deserialized relnode from this json string, the type of literal "abd" is
changed to
{noformat}
CHAR(3) NOT NULL
{noformat}
Better to keep the same with original type when deserialized from string.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (CALCITE-3350) Keep origin type for RexLiteral when deserialized from json string
[
https://issues.apache.org/jira/browse/CALCITE-3350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin updated CALCITE-3350:
-
Issue Type: Bug (was: Improvement)
> Keep origin type for RexLiteral when deserialized from json string
> --
>
> Key: CALCITE-3350
> URL: https://issues.apache.org/jira/browse/CALCITE-3350
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Priority: Minor
>
> The json string of sql
> {noformat}
> select ename from emp where job = "abd"
> {noformat}
> is
> {noformat}
> {
> "rels": [
> {
> "id": "0",
> "relOp": "LogicalTableScan",
> "table": [
> "scott",
> "EMP"
> ],
> "inputs": []
> },
> {
> "id": "1",
> "relOp": "LogicalFilter",
> "condition": {
> "op": {
> "name": "=",
> "kind": "EQUALS",
> "syntax": "BINARY"
> },
> "operands": [
> {
> "input": 2,
> "name": "$2"
> },
> {
> "literal": "abd",
> "type": {
> "type": "VARCHAR",
> "nullable": false,
> "precision": 10
> }
> }
> ]
> }
> },
> {
> "id": "2",
> "relOp": "LogicalProject",
> "fields": [
> "ENAME"
> ],
> "exprs": [
> {
> "input": 1,
> "name": "$1"
> }
> ]
> }
> ]
> }
> {noformat}
> The original type of literal "abd" is
> {noformat}
> VARCHAR(10) NOT NULL
> {noformat}
> When deserialized relnode from this json string, the type of literal "abd" is
> changed to
> {noformat}
> CHAR(3) NOT NULL
> {noformat}
> Better to keep the same with original type when deserialized from string.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (CALCITE-3334) Refinement for Substitution-Based MV Matching
[ https://issues.apache.org/jira/browse/CALCITE-3334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16931033#comment-16931033 ] Wang Yanlin commented on CALCITE-3334: -- Looking forward to this refinement. > Refinement for Substitution-Based MV Matching > - > > Key: CALCITE-3334 > URL: https://issues.apache.org/jira/browse/CALCITE-3334 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: jin xing >Priority: Major > Labels: pull-request-available > Time Spent: 50m > Remaining Estimate: 0h > > The approach of substitution-based MV matching is an effective way for its > simplicity and extensibility. > This JIRA proposes to refine existing implementation by several points: > # Canonicalize before MV matching -- by such canonicalization we can > significantly simplify the algebra tree and lower the difficulty for > materialization matching. > # Separate matching rules into two categories and enumerate common matching > patterns which need to be covered by rules. > Please check the design doc: [Design > Doc|https://docs.google.com/document/d/1JpwGNFE3hw3yXb7W3-95-jXKClZC5UFPKbuhgYDuEu4/edit#] -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (CALCITE-3347) IndexOutOfBoundsException in FixNullabilityShuttle when using FilterIntoJoinRule
[ https://issues.apache.org/jira/browse/CALCITE-3347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16931042#comment-16931042 ] Wang Yanlin commented on CALCITE-3347: -- I create a PR tries to fix this, https://github.com/apache/calcite/pull/1459 I use the test case contributed by [~lishuming] Comments are welcome. > IndexOutOfBoundsException in FixNullabilityShuttle when using > FilterIntoJoinRule > > > Key: CALCITE-3347 > URL: https://issues.apache.org/jira/browse/CALCITE-3347 > Project: Calcite > Issue Type: Bug >Affects Versions: 1.21.0 >Reporter: Amit Chavan >Priority: Major > Labels: pull-request-available > Attachments: TestCalcite.java > > Time Spent: 10m > Remaining Estimate: 0h > > I am reporting a bug that happens in calcite 1.21 release. I have a query as > below > String query = "SELECT * FROM tblspace1.tsql where n1=? and k1 in (SELECT k1 > FROM tblspace1.tsql where n1=?)"; > > I am also attaching the unit test to reproduce this issue. > > The filterJoinRule throws an exception – > java.lang.RuntimeException: Error while applying rule > FilterJoinRule:FilterJoinRule:filter, args > [rel#39:EnumerableFilter.ENUMERABLE.[](input=RelSubset#38,condition==($1, > ?0)), > rel#176:EnumerableHashJoin.ENUMERABLE.[](left=RelSubset#17,right=RelSubset#73,condition==($0, > $3),joinType=semi)] > at > org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:235) > at > org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:631) > at org.apache.calcite.TestCalcite.testQuery(TestCalcite.java:199) > at org.apache.calcite.TestCalcite.problem_with_1_21(TestCalcite.java:256) > 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:497) > 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.IndexOutOfBoundsException: index (3) must be less than > size (3) > at > com.google.common.base.Preconditions.checkElementIndex(Preconditions.java:310) > at > com.google.common.base.Preconditions.checkElementIndex(Preconditions.java:293) > at > com.google.common.collect.RegularImmutableList.get(RegularImmutableList.java:67) > at > com.google.common.collect.Lists$TransformingRandomAccessList.get(Lists.java:627) > at > org.apache.calcite.rex.RexUtil$FixNullabilityShuttle.visitInputRef(RexUtil.java:2529) > at > org.apache.calcite.rex.RexUtil$FixNullabilityShuttle.visitInputRef(RexUtil.java:2518) > at org.apache.calcite.rex.RexInputRef.accept(RexInputRef.java:112) > at org.apache.calcite.rex.RexShuttle.visitList(RexShuttle.java:149) > at org.apache.calcite.rex.RexShuttle.visitCall(RexShuttle.java:101) > at org.apache.calcite.rex.RexShuttle.visitCall(RexShuttle.java:34) > at org.apache.calcite.rex.RexCall.accept(RexCall.java:191) > at org.apache.calcite.rex.RexShuttle.apply(RexShuttle.java:277) > at org.apache.calcite.rex.RexShuttle.mutate(RexShuttle.java:239) > at org.apache.calcite.rex.RexShuttle.apply(RexShuttle.java:257) > at org.apache.calcite.rex.RexUtil.fixUp(RexUtil.java:1635) > at > org.apache.calcite
[jira] [Created] (CALCITE-3362) Implementation for some empty tests of Lattice
Wang Yanlin created CALCITE-3362: Summary: Implementation for some empty tests of Lattice Key: CALCITE-3362 URL: https://issues.apache.org/jira/browse/CALCITE-3362 Project: Calcite Issue Type: Test Reporter: Wang Yanlin When read the code of lattice framework, came across some empty unit tests in [LatticeTest|https://github.com/apache/calcite/blob/67fd318ed755ef975cf31262c96c982f0922a975/core/src/test/java/org/apache/calcite/test/LatticeTest.java#L720]. Trying to implement these empty test cases. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-3346) Enable some ignored tests in RelOptRuleTests
[ https://issues.apache.org/jira/browse/CALCITE-3346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wang Yanlin updated CALCITE-3346: - Issue Type: Test (was: Improvement) > Enable some ignored tests in RelOptRuleTests > > > Key: CALCITE-3346 > URL: https://issues.apache.org/jira/browse/CALCITE-3346 > Project: Calcite > Issue Type: Test >Reporter: Wang Yanlin >Priority: Minor > Labels: pull-request-available > Time Spent: 0.5h > Remaining Estimate: 0h > > When reading the code, i found that some ignored test case in > *RelOptRulesTest* actually can pass the test. Maybe we should try to enable > these tests. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3363) JoinUnionTransposeRule.RIGHT_UNION should not match SEMI/ANTI Join
[ https://issues.apache.org/jira/browse/CALCITE-3363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16933072#comment-16933072 ] Wang Yanlin commented on CALCITE-3363: -- Can you give some more specific examples, I cannot see why it should not. > JoinUnionTransposeRule.RIGHT_UNION should not match SEMI/ANTI Join > -- > > Key: CALCITE-3363 > URL: https://issues.apache.org/jira/browse/CALCITE-3363 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: jin xing >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > JoinUnionTransposeRule works by pull up union from below to top of join. Thus > it should not match semi/anti join by semantics. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3363) JoinUnionTransposeRule.RIGHT_UNION should not match ANTI Join
[ https://issues.apache.org/jira/browse/CALCITE-3363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16933107#comment-16933107 ] Wang Yanlin commented on CALCITE-3363: -- OK, I see. for *A anti join (B union C)* is not equals to *(A anti join B) union (A anti join C)* > JoinUnionTransposeRule.RIGHT_UNION should not match ANTI Join > - > > Key: CALCITE-3363 > URL: https://issues.apache.org/jira/browse/CALCITE-3363 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: jin xing >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > JoinUnionTransposeRule works by pull up union from below to top of join. Thus > it should not match anti join by semantics. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3373) Decorrelate boolean context IN or existential subquery directly into SEMI/ANTI join
[ https://issues.apache.org/jira/browse/CALCITE-3373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16938218#comment-16938218 ] Wang Yanlin commented on CALCITE-3373: -- I think this is a more direct way to generate semi-join. Just a little concern, might this have back compatibility issues if change in/exist to semi join directly? For some cases, user may have already change in/exist to inner join, and process without the second step, ie SemiJoinRule. So, should we have a configuration or same other way to control whether to transform in/exist to semi join? > Decorrelate boolean context IN or existential subquery directly into > SEMI/ANTI join > --- > > Key: CALCITE-3373 > URL: https://issues.apache.org/jira/browse/CALCITE-3373 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: jin xing >Priority: Major > > The current approach to generate semi-join from IN/EXISTS is as below: > # Decorrelation > # Transforming by SemiJoinRule to get a semi-join > A more straightforward approach is to generate the semi-join right in > Decorrelation. > What's more, we should also have an approach to generate anti-join right in > Decorrelation.(Currently there's no analogous rule to SemiJoinRule for > anti-join) > This one is related to CALCITE-3367 > -- This message was sent by Atlassian Jira (v8.3.4#803005)
