[jira] [Commented] (CALCITE-3351) calcite mysql utf8 throws exception in Chinese
[
https://issues.apache.org/jira/browse/CALCITE-3351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16931072#comment-16931072
]
Danny Chan commented on CALCITE-3351:
-
The exception is thrown from avatica, and it seems that it is related with
CALCITE-2704, there is already a fix from [~vlsi][1].
[1] [https://github.com/apache/calcite-avatica/pull/85]
> calcite mysql utf8 throws exception in Chinese
> --
>
> Key: CALCITE-3351
> URL: https://issues.apache.org/jira/browse/CALCITE-3351
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.19.0
> Environment: Happened on both Windows and MacOS.
>Reporter: cui
>Priority: Major
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Exception was thrown when connecting with mySQL to query Chinese. The
> following SQL was executed:
> select * from \"test\".\"score_new\" where \"name\"= \'催\' limit 1
> ，if change "getDefaultCharset" in "RelDataTypeFactoryImpl" to
> return Charset.forName("UTF8");
> there will be also exception thrown as the following:
> java.sql.SQLException: Error while executing SQL "select * from
> "test"."score_new" where "name"= '催' limit 1": While executing SQL [SELECT
> *java.sql.SQLException: Error while executing SQL "select * from
> "test"."score_new" where "name"= '催' limit 1": While executing SQL [SELECT
> *FROM `score_new`WHERE `name` = u&'\50ac'LIMIT 1] on JDBC sub-schema at
> org.apache.calcite.avatica.Helper.createException(Helper.java:56) at
> org.apache.calcite.avatica.Helper.createException(Helper.java:41) at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:163)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:227)
> at QueryMysql.main(QueryMysql.java:42)Caused by: java.lang.RuntimeException:
> While executing SQL [SELECT *FROM `score_new`WHERE `name` = u&'\50ac'
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (CALCITE-3349) Add Function DDL into SqlKind DDL enum
[ https://issues.apache.org/jira/browse/CALCITE-3349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16931053#comment-16931053 ] Zhenqiu Huang commented on CALCITE-3349: [~danny0405] Agree. But I don't find any good way to test it efficiently. Any suggestion? > Add Function DDL into SqlKind DDL enum > -- > > Key: CALCITE-3349 > URL: https://issues.apache.org/jira/browse/CALCITE-3349 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Zhenqiu Huang >Priority: Minor > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > Currently, Create Function, Drop Function are not added into SqlKind DDL > enum. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (CALCITE-3349) Add Function DDL into SqlKind DDL enum
[ https://issues.apache.org/jira/browse/CALCITE-3349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16931052#comment-16931052 ] Zhenqiu Huang commented on CALCITE-3349: [~lishuming] It is true. As the goal of PR is limited to just add SqlKind enum. Probably a separate PR is needed for changing both SqlCreateFunction and SqlDropFunction. > Add Function DDL into SqlKind DDL enum > -- > > Key: CALCITE-3349 > URL: https://issues.apache.org/jira/browse/CALCITE-3349 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Zhenqiu Huang >Priority: Minor > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > Currently, Create Function, Drop Function are not added into SqlKind DDL > enum. -- 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] [Updated] (CALCITE-3347) IndexOutOfBoundsException in FixNullabilityShuttle when using FilterIntoJoinRule
[ https://issues.apache.org/jira/browse/CALCITE-3347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-3347: Labels: pull-request-available (was: ) > 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 > > > 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.rel.rules.FilterJoinRule.perform(FilterJoinRule.java:284) > at > org.apache.calcite.rel.rules.FilterJoinRule$FilterIntoJoinRule.onMatch(FilterJoinRule.java:383) > at > org.apache.calcite.plan.volcano.Volcan
[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-3351) calcite mysql utf8 throws exception in Chinese
[
https://issues.apache.org/jira/browse/CALCITE-3351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16931018#comment-16931018
]
cui commented on CALCITE-3351:
--
Thanks for translating,this is the first to commit JIRA,next I will commit in
English.
> calcite mysql utf8 throws exception in Chinese
> --
>
> Key: CALCITE-3351
> URL: https://issues.apache.org/jira/browse/CALCITE-3351
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.19.0
> Environment: Happened on both Windows and MacOS.
>Reporter: cui
>Priority: Major
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Exception was thrown when connecting with mySQL to query Chinese. The
> following SQL was executed:
> select * from \"test\".\"score_new\" where \"name\"= \'催\' limit 1
> ，if change "getDefaultCharset" in "RelDataTypeFactoryImpl" to
> return Charset.forName("UTF8");
> there will be also exception thrown as the following:
> java.sql.SQLException: Error while executing SQL "select * from
> "test"."score_new" where "name"= '催' limit 1": While executing SQL [SELECT
> *java.sql.SQLException: Error while executing SQL "select * from
> "test"."score_new" where "name"= '催' limit 1": While executing SQL [SELECT
> *FROM `score_new`WHERE `name` = u&'\50ac'LIMIT 1] on JDBC sub-schema at
> org.apache.calcite.avatica.Helper.createException(Helper.java:56) at
> org.apache.calcite.avatica.Helper.createException(Helper.java:41) at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:163)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:227)
> at QueryMysql.main(QueryMysql.java:42)Caused by: java.lang.RuntimeException:
> While executing SQL [SELECT *FROM `score_new`WHERE `name` = u&'\50ac'
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (CALCITE-3340) Make TUMBLE be accepted as an operand for "FROM TABLE()" in validator
[
https://issues.apache.org/jira/browse/CALCITE-3340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16930915#comment-16930915
]
Julian Hyde commented on CALCITE-3340:
--
* Is it required that table-valued functions extend
SqlTableValueFunctionWindowingOperator? I don't think so. I'm not sure that a
"windowing operator" is a thing that Calcite cares about.
* PlannerTest is the place for tests of the planner. Not for tests that merely
use the planner. Maybe add stream.iq, similar to join.iq, and run it using
CoreQuidemTest.
* I am a bit surprised that TUMBLE appears in switch statements alongside
OTHER_FUNCTION. Do we currently require user-defined table functions to be of
type OTHER_FUNCTION?
* I know this is a prototype, but it's easier to review if other stuff is
clean (tests pass, checkstyle passes).
> Make TUMBLE be accepted as an operand for "FROM TABLE()" in validator
> -
>
> Key: CALCITE-3340
> URL: https://issues.apache.org/jira/browse/CALCITE-3340
> Project: Calcite
> Issue Type: Sub-task
>Reporter: Rui Wang
>Assignee: Rui Wang
>Priority: Major
> Labels: pull-request-available
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The goal of this JIRA is to generate a logical plan for the following query:
> {code:java}
> SELECT *
> FROM TABLE(TUMBLE(
> TABLE ORDERS,
> INTERVAL '10' MINUTE))
> {code}
> This SQL query does not have DESCRIPTOR included, which is being tracked and
> discussed by CALCITE-3339.
> I expect we should generate a logical plan from this query that is similar to
> the following:
> {code:java}
> LogicalProject(ROWTIME=[$0], ID=[$1], PRODUCT=[$2], UNITS=[$3], wstart=[$4],
> wend=[$5])
> LogicalTableFunctionScan(invocation=[TUMBLE($3, 6:INTERVAL MINUTE)],
> rowType=[RecordType(TIMESTAMP(0) ROWTIME, INTEGER ID, VARCHAR(10) PRODUCT,
> INTEGER UNITS, TIMESTAMP(0) wstart, TIMESTAMP(0) wend)])
> LogicalProject(ROWTIME=[$0], ID=[$1], PRODUCT=[$2], UNITS=[$3])
> LogicalTableScan(table=[[ORINOCO, ORDERS]])
> {code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (CALCITE-3340) Make TUMBLE be accepted as an operand for "FROM TABLE()" in validator
[
https://issues.apache.org/jira/browse/CALCITE-3340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16930897#comment-16930897
]
Rui Wang commented on CALCITE-3340:
---
[~julianhyde]
I have updated this JIRA to clarify my goal and also cleaned up #1457 (use
TUMBLE, add javadoc, cleanup unnecessary changes, etc.) Could you please take
another look?
> Make TUMBLE be accepted as an operand for "FROM TABLE()" in validator
> -
>
> Key: CALCITE-3340
> URL: https://issues.apache.org/jira/browse/CALCITE-3340
> Project: Calcite
> Issue Type: Sub-task
>Reporter: Rui Wang
>Assignee: Rui Wang
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The goal of this JIRA is to generate a logical plan for the following query:
> {code:java}
> SELECT *
> FROM TABLE(TUMBLE(
> TABLE ORDERS,
> INTERVAL '10' MINUTE))
> {code}
> This SQL query does not have DESCRIPTOR included, which is being tracked and
> discussed by CALCITE-3339.
> I expect we should generate a logical plan from this query that is similar to
> the following:
> {code:java}
> LogicalProject(ROWTIME=[$0], ID=[$1], PRODUCT=[$2], UNITS=[$3], wstart=[$4],
> wend=[$5])
> LogicalTableFunctionScan(invocation=[TUMBLE($3, 6:INTERVAL MINUTE)],
> rowType=[RecordType(TIMESTAMP(0) ROWTIME, INTEGER ID, VARCHAR(10) PRODUCT,
> INTEGER UNITS, TIMESTAMP(0) wstart, TIMESTAMP(0) wend)])
> LogicalProject(ROWTIME=[$0], ID=[$1], PRODUCT=[$2], UNITS=[$3])
> LogicalTableScan(table=[[ORINOCO, ORDERS]])
> {code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (CALCITE-3340) Make TUMBLE be accepted as an operand for "FROM TABLE()" in validator
[
https://issues.apache.org/jira/browse/CALCITE-3340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rui Wang updated CALCITE-3340:
--
Description:
The goal of this JIRA is to generate a logical plan for the following query:
{code:java}
SELECT *
FROM TABLE(TUMBLE(
TABLE ORDERS,
INTERVAL '10' MINUTE))
{code}
This SQL query does not have DESCRIPTOR included, which is being tracked and
discussed by CALCITE-3339.
I expect we should generate a logical plan from this query that is similar to
the following:
{code:java}
LogicalProject(ROWTIME=[$0], ID=[$1], PRODUCT=[$2], UNITS=[$3], wstart=[$4],
wend=[$5])
LogicalTableFunctionScan(invocation=[TUMBLE($3, 6:INTERVAL MINUTE)],
rowType=[RecordType(TIMESTAMP(0) ROWTIME, INTEGER ID, VARCHAR(10) PRODUCT,
INTEGER UNITS, TIMESTAMP(0) wstart, TIMESTAMP(0) wend)])
LogicalProject(ROWTIME=[$0], ID=[$1], PRODUCT=[$2], UNITS=[$3])
LogicalTableScan(table=[[ORINOCO, ORDERS]])
{code}
was:
For query:
SELECT *
FROM TABLE(TUMBLE(
TABLE ORDERS,
DESCRIPTOR(ROWTIME),
INTERVAL '10' MINUTE))
(note reuse TUMBLE operator than use a new unresolved one)
Calcite validator will does a step to do registration and "TABLE(TUMBLE(...))"
will hit [1], where "TUMBLE(...)" will be passed to [2] again but there is no
matching Sqlkind handling for "TUMBLE" (note that TUMBLE's node kind is
TUMBLE).
It seems we should support TUMBLE in [2]. The details of how to support it
needs a bit more discussion and prototyping.
[1]:
https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/validate/SqlValidatorImpl.java#L2244
[2]:https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/validate/SqlValidatorImpl.java#L2031
> Make TUMBLE be accepted as an operand for "FROM TABLE()" in validator
> -
>
> Key: CALCITE-3340
> URL: https://issues.apache.org/jira/browse/CALCITE-3340
> Project: Calcite
> Issue Type: Sub-task
>Reporter: Rui Wang
>Assignee: Rui Wang
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The goal of this JIRA is to generate a logical plan for the following query:
> {code:java}
> SELECT *
> FROM TABLE(TUMBLE(
> TABLE ORDERS,
> INTERVAL '10' MINUTE))
> {code}
> This SQL query does not have DESCRIPTOR included, which is being tracked and
> discussed by CALCITE-3339.
> I expect we should generate a logical plan from this query that is similar to
> the following:
> {code:java}
> LogicalProject(ROWTIME=[$0], ID=[$1], PRODUCT=[$2], UNITS=[$3], wstart=[$4],
> wend=[$5])
> LogicalTableFunctionScan(invocation=[TUMBLE($3, 6:INTERVAL MINUTE)],
> rowType=[RecordType(TIMESTAMP(0) ROWTIME, INTEGER ID, VARCHAR(10) PRODUCT,
> INTEGER UNITS, TIMESTAMP(0) wstart, TIMESTAMP(0) wend)])
> LogicalProject(ROWTIME=[$0], ID=[$1], PRODUCT=[$2], UNITS=[$3])
> LogicalTableScan(table=[[ORINOCO, ORDERS]])
> {code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (CALCITE-3345) Implement time_bucket function
[
https://issues.apache.org/jira/browse/CALCITE-3345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16930847#comment-16930847
]
Julian Hyde commented on CALCITE-3345:
--
We could follow the same approach as for other function sets: add an enum
constant 'TIMESCALE_DB' to enum SqlLibrary, and add a library function. For
comparison, see
[00ad79b6|https://github.com/apache/calcite/commit/00ad79b6bc95b68e02129b31be8a3a656517f8a8]
which fixes CALCITE-3263 and adds {{MD5}} and {{SHA1}} to MYSQL and POSTGRESQL
libraries.
I had a quick look at timescaleDB and there is some un-SQL-like stuff in there
that we would not wish to emulate, such as [this
behavior|https://docs.timescale.com/latest/api#time_bucket_gapfill] for
{{time_bucket_gapfill}}:
{quote}Starting with version 1.3.0 start and finish are optional arguments and
will be inferred from the WHERE clause if not supplied as arguments.{quote}
I have no objection to bringing in scalar functions into a timescaleDB
compatibility library, but if we start screwing around with SQL/relational
semantics it's going to be a long discussion. :)
> Implement time_bucket function
> --
>
> Key: CALCITE-3345
> URL: https://issues.apache.org/jira/browse/CALCITE-3345
> Project: Calcite
> Issue Type: New Feature
>Reporter: Julian Feinauer
>Priority: Major
>
> See here for information on the `time_bucket` function:
> https://docs.timescale.com/latest/api#time_bucket
> This is a more powerful version of the standard PostgreSQL date_trunc
> function. It allows for arbitrary time intervals instead of the second,
> minute, hour, etc. provided by date_trunc. The return value is the bucket's
> start time.
> This would especially help with time averaging but keeps everything SQL
> compliant. E.g. queries like
> Example query from (https://www.timescale.com/):
> {code:sql}
> SELECT time_bucket('10 seconds', time) AS ten_second,
> machine_id, avg(temperature) AS "avgT",
> min(temperature) AS "minT", max(temperature) AS "maxT",
> last(temperature, time) AS "lastT"
> FROM measurements
> WHERE machine_id = 'C931baF7'
> AND time > now() - interval '150s'
> GROUP BY ten_second
> ORDER BY ten_second DESC;
> {code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Comment Edited] (CALCITE-3340) Make TUMBLE be accepted as an operand for "FROM TABLE()" in validator
[
https://issues.apache.org/jira/browse/CALCITE-3340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16930845#comment-16930845
]
Rui Wang edited comment on CALCITE-3340 at 9/16/19 8:30 PM:
I see. Thanks for bringing it up.
To clarify, I am aiming to generate a logical plan for the following query by
PlannerImpl:
SELECT *
FROM TABLE(TUMBLE(
TABLE ORDERS,
INTERVAL '10' MINUTE))
This SQL query does not have DESCRIPTOR included, which is being tracked and
discussed by CALCITE-3339.
I expect we should generate a logical plan from this query that is similar to
the following:
{code:java}
LogicalProject(ROWTIME=[$0], ID=[$1], PRODUCT=[$2], UNITS=[$3], wstart=[$4],
wend=[$5])
LogicalTableFunctionScan(invocation=[TUMBLE($3, 6:INTERVAL MINUTE)],
rowType=[RecordType(TIMESTAMP(0) ROWTIME, INTEGER ID, VARCHAR(10) PRODUCT,
INTEGER UNITS, TIMESTAMP(0) wstart, TIMESTAMP(0) wend)])
LogicalProject(ROWTIME=[$0], ID=[$1], PRODUCT=[$2], UNITS=[$3])
LogicalTableScan(table=[[ORINOCO, ORDERS]])
{code}
I just updated JIRA title a bit and hopeful now it is more understandable.
was (Author: amaliujia):
I see. Thanks for bringing it up.
To clarify, I am aiming to generate a logical plan for the following query by
PlannerImpl:
SELECT *
FROM TABLE(TUMBLE(
TABLE ORDERS,
INTERVAL '10' MINUTE))
This SQL query does not have DESCRIPTOR included, which is being tracked and
discussed by CALCITE-3339.
I expect we should generate a logical plan from this query that is similar to
the following:
{code:java}
LogicalProject(ROWTIME=[$0], ID=[$1], PRODUCT=[$2], UNITS=[$3], wstart=[$4],
wend=[$5])
LogicalTableFunctionScan(invocation=[TUMBLE($3, 6:INTERVAL MINUTE)],
rowType=[RecordType(TIMESTAMP(0) ROWTIME, INTEGER ID, VARCHAR(10) PRODUCT,
INTEGER UNITS, TIMESTAMP(0) wstart, TIMESTAMP(0) wend)])
LogicalProject(ROWTIME=[$0], ID=[$1], PRODUCT=[$2], UNITS=[$3])
LogicalTableScan(table=[[ORINOCO, ORDERS]])
{code}
> Make TUMBLE be accepted as an operand for "FROM TABLE()" in validator
> -
>
> Key: CALCITE-3340
> URL: https://issues.apache.org/jira/browse/CALCITE-3340
> Project: Calcite
> Issue Type: Sub-task
>Reporter: Rui Wang
>Assignee: Rui Wang
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> For query:
> SELECT *
> FROM TABLE(TUMBLE(
> TABLE ORDERS,
> DESCRIPTOR(ROWTIME),
> INTERVAL '10' MINUTE))
> (note reuse TUMBLE operator than use a new unresolved one)
> Calcite validator will does a step to do registration and
> "TABLE(TUMBLE(...))" will hit [1], where "TUMBLE(...)" will be passed to [2]
> again but there is no matching Sqlkind handling for "TUMBLE" (note that
> TUMBLE's node kind is TUMBLE).
> It seems we should support TUMBLE in [2]. The details of how to support it
> needs a bit more discussion and prototyping.
> [1]:
> https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/validate/SqlValidatorImpl.java#L2244
> [2]:https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/validate/SqlValidatorImpl.java#L2031
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Comment Edited] (CALCITE-3340) Make TUMBLE be accepted as an operand for "FROM TABLE()" in validator
[
https://issues.apache.org/jira/browse/CALCITE-3340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16930845#comment-16930845
]
Rui Wang edited comment on CALCITE-3340 at 9/16/19 8:30 PM:
I see. Thanks for bringing it up.
To clarify, I am aiming to generate a logical plan for the following query by
PlannerImpl:
{code:java}
SELECT *
FROM TABLE(TUMBLE(
TABLE ORDERS,
INTERVAL '10' MINUTE))
{code}
This SQL query does not have DESCRIPTOR included, which is being tracked and
discussed by CALCITE-3339.
I expect we should generate a logical plan from this query that is similar to
the following:
{code:java}
LogicalProject(ROWTIME=[$0], ID=[$1], PRODUCT=[$2], UNITS=[$3], wstart=[$4],
wend=[$5])
LogicalTableFunctionScan(invocation=[TUMBLE($3, 6:INTERVAL MINUTE)],
rowType=[RecordType(TIMESTAMP(0) ROWTIME, INTEGER ID, VARCHAR(10) PRODUCT,
INTEGER UNITS, TIMESTAMP(0) wstart, TIMESTAMP(0) wend)])
LogicalProject(ROWTIME=[$0], ID=[$1], PRODUCT=[$2], UNITS=[$3])
LogicalTableScan(table=[[ORINOCO, ORDERS]])
{code}
I just updated JIRA title a bit and hopeful now it is more understandable.
was (Author: amaliujia):
I see. Thanks for bringing it up.
To clarify, I am aiming to generate a logical plan for the following query by
PlannerImpl:
SELECT *
FROM TABLE(TUMBLE(
TABLE ORDERS,
INTERVAL '10' MINUTE))
This SQL query does not have DESCRIPTOR included, which is being tracked and
discussed by CALCITE-3339.
I expect we should generate a logical plan from this query that is similar to
the following:
{code:java}
LogicalProject(ROWTIME=[$0], ID=[$1], PRODUCT=[$2], UNITS=[$3], wstart=[$4],
wend=[$5])
LogicalTableFunctionScan(invocation=[TUMBLE($3, 6:INTERVAL MINUTE)],
rowType=[RecordType(TIMESTAMP(0) ROWTIME, INTEGER ID, VARCHAR(10) PRODUCT,
INTEGER UNITS, TIMESTAMP(0) wstart, TIMESTAMP(0) wend)])
LogicalProject(ROWTIME=[$0], ID=[$1], PRODUCT=[$2], UNITS=[$3])
LogicalTableScan(table=[[ORINOCO, ORDERS]])
{code}
I just updated JIRA title a bit and hopeful now it is more understandable.
> Make TUMBLE be accepted as an operand for "FROM TABLE()" in validator
> -
>
> Key: CALCITE-3340
> URL: https://issues.apache.org/jira/browse/CALCITE-3340
> Project: Calcite
> Issue Type: Sub-task
>Reporter: Rui Wang
>Assignee: Rui Wang
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> For query:
> SELECT *
> FROM TABLE(TUMBLE(
> TABLE ORDERS,
> DESCRIPTOR(ROWTIME),
> INTERVAL '10' MINUTE))
> (note reuse TUMBLE operator than use a new unresolved one)
> Calcite validator will does a step to do registration and
> "TABLE(TUMBLE(...))" will hit [1], where "TUMBLE(...)" will be passed to [2]
> again but there is no matching Sqlkind handling for "TUMBLE" (note that
> TUMBLE's node kind is TUMBLE).
> It seems we should support TUMBLE in [2]. The details of how to support it
> needs a bit more discussion and prototyping.
> [1]:
> https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/validate/SqlValidatorImpl.java#L2244
> [2]:https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/validate/SqlValidatorImpl.java#L2031
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (CALCITE-3340) Make TUMBLE be accepted as an operand for "FROM TABLE()" in validator
[ https://issues.apache.org/jira/browse/CALCITE-3340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rui Wang updated CALCITE-3340: -- Summary: Make TUMBLE be accepted as an operand for "FROM TABLE()" in validator (was: Make TUMBLE be accepted as an operand for COLLECTION_TABLE(TABLE syntax) in validator) > Make TUMBLE be accepted as an operand for "FROM TABLE()" in validator > - > > Key: CALCITE-3340 > URL: https://issues.apache.org/jira/browse/CALCITE-3340 > Project: Calcite > Issue Type: Sub-task >Reporter: Rui Wang >Assignee: Rui Wang >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > For query: > SELECT * > FROM TABLE(TUMBLE( > TABLE ORDERS, > DESCRIPTOR(ROWTIME), > INTERVAL '10' MINUTE)) > (note reuse TUMBLE operator than use a new unresolved one) > Calcite validator will does a step to do registration and > "TABLE(TUMBLE(...))" will hit [1], where "TUMBLE(...)" will be passed to [2] > again but there is no matching Sqlkind handling for "TUMBLE" (note that > TUMBLE's node kind is TUMBLE). > It seems we should support TUMBLE in [2]. The details of how to support it > needs a bit more discussion and prototyping. > [1]: > https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/validate/SqlValidatorImpl.java#L2244 > [2]:https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/validate/SqlValidatorImpl.java#L2031 -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (CALCITE-3340) Make TUMBLE be accepted as an operand for COLLECTION_TABLE(TABLE syntax) in validator
[
https://issues.apache.org/jira/browse/CALCITE-3340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16930845#comment-16930845
]
Rui Wang commented on CALCITE-3340:
---
I see. Thanks for bringing it up.
To clarify, I am aiming to generate a logical plan for the following query by
PlannerImpl:
SELECT *
FROM TABLE(TUMBLE(
TABLE ORDERS,
INTERVAL '10' MINUTE))
This SQL query does not have DESCRIPTOR included, which is being tracked and
discussed by CALCITE-3339.
I expect we should generate a logical plan from this query that is similar to
the following:
{code:java}
LogicalProject(ROWTIME=[$0], ID=[$1], PRODUCT=[$2], UNITS=[$3], wstart=[$4],
wend=[$5])
LogicalTableFunctionScan(invocation=[TUMBLE($3, 6:INTERVAL MINUTE)],
rowType=[RecordType(TIMESTAMP(0) ROWTIME, INTEGER ID, VARCHAR(10) PRODUCT,
INTEGER UNITS, TIMESTAMP(0) wstart, TIMESTAMP(0) wend)])
LogicalProject(ROWTIME=[$0], ID=[$1], PRODUCT=[$2], UNITS=[$3])
LogicalTableScan(table=[[ORINOCO, ORDERS]])
{code}
> Make TUMBLE be accepted as an operand for COLLECTION_TABLE(TABLE syntax) in
> validator
> -
>
> Key: CALCITE-3340
> URL: https://issues.apache.org/jira/browse/CALCITE-3340
> Project: Calcite
> Issue Type: Sub-task
>Reporter: Rui Wang
>Assignee: Rui Wang
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> For query:
> SELECT *
> FROM TABLE(TUMBLE(
> TABLE ORDERS,
> DESCRIPTOR(ROWTIME),
> INTERVAL '10' MINUTE))
> (note reuse TUMBLE operator than use a new unresolved one)
> Calcite validator will does a step to do registration and
> "TABLE(TUMBLE(...))" will hit [1], where "TUMBLE(...)" will be passed to [2]
> again but there is no matching Sqlkind handling for "TUMBLE" (note that
> TUMBLE's node kind is TUMBLE).
> It seems we should support TUMBLE in [2]. The details of how to support it
> needs a bit more discussion and prototyping.
> [1]:
> https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/validate/SqlValidatorImpl.java#L2244
> [2]:https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/validate/SqlValidatorImpl.java#L2031
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (CALCITE-3340) Make TUMBLE be accepted as an operand for COLLECTION_TABLE(TABLE syntax) in validator
[ https://issues.apache.org/jira/browse/CALCITE-3340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16930838#comment-16930838 ] Julian Hyde commented on CALCITE-3340: -- I don't really understand any of this case. Let's start with the first line, "COLLECTION_TABLE(TABLE syntax)". "COLLECTION_TABLE" isn't a keyword in SQL, so I'm totally confused. Then the description starts talking about code, e.g. what particular lines of SqlValidatorImpl are doing or should be doing. Can we start with a goal, e.g. a particular SQL query that we wish to be able to run, and the results it should give. > Make TUMBLE be accepted as an operand for COLLECTION_TABLE(TABLE syntax) in > validator > - > > Key: CALCITE-3340 > URL: https://issues.apache.org/jira/browse/CALCITE-3340 > Project: Calcite > Issue Type: Sub-task >Reporter: Rui Wang >Assignee: Rui Wang >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > For query: > SELECT * > FROM TABLE(TUMBLE( > TABLE ORDERS, > DESCRIPTOR(ROWTIME), > INTERVAL '10' MINUTE)) > (note reuse TUMBLE operator than use a new unresolved one) > Calcite validator will does a step to do registration and > "TABLE(TUMBLE(...))" will hit [1], where "TUMBLE(...)" will be passed to [2] > again but there is no matching Sqlkind handling for "TUMBLE" (note that > TUMBLE's node kind is TUMBLE). > It seems we should support TUMBLE in [2]. The details of how to support it > needs a bit more discussion and prototyping. > [1]: > https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/validate/SqlValidatorImpl.java#L2244 > [2]:https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/validate/SqlValidatorImpl.java#L2031 -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (CALCITE-3340) Make TUMBLE be accepted as an operand for COLLECTION_TABLE(TABLE syntax) in validator
[ https://issues.apache.org/jira/browse/CALCITE-3340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-3340: Labels: pull-request-available (was: ) > Make TUMBLE be accepted as an operand for COLLECTION_TABLE(TABLE syntax) in > validator > - > > Key: CALCITE-3340 > URL: https://issues.apache.org/jira/browse/CALCITE-3340 > Project: Calcite > Issue Type: Sub-task >Reporter: Rui Wang >Assignee: Rui Wang >Priority: Major > Labels: pull-request-available > > For query: > SELECT * > FROM TABLE(TUMBLE( > TABLE ORDERS, > DESCRIPTOR(ROWTIME), > INTERVAL '10' MINUTE)) > (note reuse TUMBLE operator than use a new unresolved one) > Calcite validator will does a step to do registration and > "TABLE(TUMBLE(...))" will hit [1], where "TUMBLE(...)" will be passed to [2] > again but there is no matching Sqlkind handling for "TUMBLE" (note that > TUMBLE's node kind is TUMBLE). > It seems we should support TUMBLE in [2]. The details of how to support it > needs a bit more discussion and prototyping. > [1]: > https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/validate/SqlValidatorImpl.java#L2244 > [2]:https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/validate/SqlValidatorImpl.java#L2031 -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (CALCITE-3340) Make TUMBLE be accepted as an operand for COLLECTION_TABLE(TABLE syntax) in validator
[ https://issues.apache.org/jira/browse/CALCITE-3340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16930789#comment-16930789 ] Rui Wang commented on CALCITE-3340: --- "TUMBLE_TABLE_FUNCTION" was a quick decision to skip some changes in validator. Ok, the next I will do is: 1. change "TUMBLE_TABLE_FUNCTION" back to "TUMBLE" (and more changes in validator) 2. correct formatting. 3. more javadoc/comments to explain the code. After this is done I will let you know. > Make TUMBLE be accepted as an operand for COLLECTION_TABLE(TABLE syntax) in > validator > - > > Key: CALCITE-3340 > URL: https://issues.apache.org/jira/browse/CALCITE-3340 > Project: Calcite > Issue Type: Sub-task >Reporter: Rui Wang >Assignee: Rui Wang >Priority: Major > > For query: > SELECT * > FROM TABLE(TUMBLE( > TABLE ORDERS, > DESCRIPTOR(ROWTIME), > INTERVAL '10' MINUTE)) > (note reuse TUMBLE operator than use a new unresolved one) > Calcite validator will does a step to do registration and > "TABLE(TUMBLE(...))" will hit [1], where "TUMBLE(...)" will be passed to [2] > again but there is no matching Sqlkind handling for "TUMBLE" (note that > TUMBLE's node kind is TUMBLE). > It seems we should support TUMBLE in [2]. The details of how to support it > needs a bit more discussion and prototyping. > [1]: > https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/validate/SqlValidatorImpl.java#L2244 > [2]:https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/validate/SqlValidatorImpl.java#L2031 -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (CALCITE-3340) Make TUMBLE be accepted as an operand for COLLECTION_TABLE(TABLE syntax) in validator
[ https://issues.apache.org/jira/browse/CALCITE-3340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16930783#comment-16930783 ] Julian Hyde commented on CALCITE-3340: -- Well, the PR doesn't do quite what the JIRA case promises. You've added a table function called "TUMBLE_TABLE_FUNCTION" not "TUMBLE". I see a couple of spurious changes in formatting, and a lot of classes, methods and fields added with no javadoc. Without javadoc it's difficult to know the intent of this code. > Make TUMBLE be accepted as an operand for COLLECTION_TABLE(TABLE syntax) in > validator > - > > Key: CALCITE-3340 > URL: https://issues.apache.org/jira/browse/CALCITE-3340 > Project: Calcite > Issue Type: Sub-task >Reporter: Rui Wang >Assignee: Rui Wang >Priority: Major > > For query: > SELECT * > FROM TABLE(TUMBLE( > TABLE ORDERS, > DESCRIPTOR(ROWTIME), > INTERVAL '10' MINUTE)) > (note reuse TUMBLE operator than use a new unresolved one) > Calcite validator will does a step to do registration and > "TABLE(TUMBLE(...))" will hit [1], where "TUMBLE(...)" will be passed to [2] > again but there is no matching Sqlkind handling for "TUMBLE" (note that > TUMBLE's node kind is TUMBLE). > It seems we should support TUMBLE in [2]. The details of how to support it > needs a bit more discussion and prototyping. > [1]: > https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/validate/SqlValidatorImpl.java#L2244 > [2]:https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/validate/SqlValidatorImpl.java#L2031 -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (CALCITE-2772) Support varargs for user-defined functions (UDFs)
[
https://issues.apache.org/jira/browse/CALCITE-2772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16930771#comment-16930771
]
Julian Hyde commented on CALCITE-2772:
--
Reviewing the PR.
* Can you do a "git diff" and remove the formatting changes that are not
improvements? (Some of them are improvements.)
* Improve the javadoc comments. For example, "Returns the function is var args
or not." is a circular definition. In that same function, which returns
`boolean`, "@return Boolean" is not only useless, it is untrue. The key thing
to explain to developers and users alike that a function with N parameters that
is varargs can accept N-1, N, N+1, N+2,... arguments, and the extra arguments
all have the same type.
* Does it make sense to have `FunctionParameter.isVarArgs()`? Only the last
parameter can be variable. It's really a property of the method, not the
parameter.
* Let's have some positive and negative SQL validation tests. You should be
thinking of this feature, and describing it, in terms of the effect on the SQL
user.
* What happens if you combine arrays and varargs. For example, what SQL
function signatures do you expect `public static void foo(int x, String[]
args...)` to generate? I think it needs a test.
* Why a maximum of 1200 arguments? I don't see a reason to have a maximum.
> Support varargs for user-defined functions (UDFs)
> -
>
> Key: CALCITE-2772
> URL: https://issues.apache.org/jira/browse/CALCITE-2772
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: pengzhiwei
>Assignee: pengzhiwei
>Priority: Major
> Labels: pull-request-available
> Attachments: support_varargs_udf.patch
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Support varargs for user-defined functions as the case followed:
> {code:java}
> public class ConcatWs {
> public String eval(String sep, String... strs) {...}
> }{code}
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (CALCITE-3340) Make TUMBLE be accepted as an operand for COLLECTION_TABLE(TABLE syntax) in validator
[ https://issues.apache.org/jira/browse/CALCITE-3340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16930758#comment-16930758 ] Rui Wang commented on CALCITE-3340: --- [~julianhyde] Could you please give some feedback on this prototype PR directly: https://github.com/apache/calcite/pull/1457? I am a little confused on old/new operators suggestions/questions. > Make TUMBLE be accepted as an operand for COLLECTION_TABLE(TABLE syntax) in > validator > - > > Key: CALCITE-3340 > URL: https://issues.apache.org/jira/browse/CALCITE-3340 > Project: Calcite > Issue Type: Sub-task >Reporter: Rui Wang >Assignee: Rui Wang >Priority: Major > > For query: > SELECT * > FROM TABLE(TUMBLE( > TABLE ORDERS, > DESCRIPTOR(ROWTIME), > INTERVAL '10' MINUTE)) > (note reuse TUMBLE operator than use a new unresolved one) > Calcite validator will does a step to do registration and > "TABLE(TUMBLE(...))" will hit [1], where "TUMBLE(...)" will be passed to [2] > again but there is no matching Sqlkind handling for "TUMBLE" (note that > TUMBLE's node kind is TUMBLE). > It seems we should support TUMBLE in [2]. The details of how to support it > needs a bit more discussion and prototyping. > [1]: > https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/validate/SqlValidatorImpl.java#L2244 > [2]:https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/validate/SqlValidatorImpl.java#L2031 -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (CALCITE-3272) TUMBLE Table Value Function
[ https://issues.apache.org/jira/browse/CALCITE-3272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-3272: Labels: pull-request-available (was: ) > TUMBLE Table Value Function > --- > > Key: CALCITE-3272 > URL: https://issues.apache.org/jira/browse/CALCITE-3272 > Project: Calcite > Issue Type: Sub-task >Reporter: Rui Wang >Assignee: Rui Wang >Priority: Major > Labels: pull-request-available > > Define a builtin TVF: Tumble (data , timecol , dur, [ offset ]) > The return value of Tumble is a relation that includes all columns of data as > well as additional event time columns wstart and wend. > Examples of TUMBLE TVF are (from https://s.apache.org/streaming-beam-sql ): > 8:21> SELECT * FROM Bid; > -- > | bidtime | price | item | > -- > | 8:07| $2| A| > | 8:11| $3| B| > | 8:05| $4| C| > | 8:09| $5| D| > | 8:13| $1| E| > | 8:17| $6| F| > -- > 8:21> SELECT * > FROM TABLE Tumble ( > data=> TABLE Bid , > timecol => DESCRIPTOR ( bidtime ) , > dur => INTERVAL '10' MINUTES , > offset => INTERVAL '0' MINUTES ); > -- > | wstart | wend | bidtime | price | item | > -- > | 8:00 | 8:10 | 8:07| $2| A| > | 8:10 | 8:20 | 8:11| $3| B| > | 8:00 | 8:10 | 8:05| $4| C| > | 8:00 | 8:10 | 8:09| $5| D| > | 8:10 | 8:20 | 8:13| $1| E| > | 8:10 | 8:20 | 8:17| $6| F| > -- > 8:21> SELECT MAX ( wstart ) , wend , SUM ( price ) > FROM TABLE Tumble ( > data=> TABLE ( Bid ) , > timecol => DESCRIPTOR ( bidtime ) , > dur => INTERVAL '10 ' MINUTES ) > GROUP BY wend; > - > | wstart | wend | price | > - > | 8:00 | 8:10 | $11 | > | 8:10 | 8:20 | $10 | > - -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (CALCITE-3351) calcite mysql utf8 throws exception in Chinese
[
https://issues.apache.org/jira/browse/CALCITE-3351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16930750#comment-16930750
]
Rui Wang commented on CALCITE-3351:
---
I translated this JIRA to English for better communication.
Contributions will always be welcomed(looks like we need them on Chinese
support in Calcite).
> calcite mysql utf8 throws exception in Chinese
> --
>
> Key: CALCITE-3351
> URL: https://issues.apache.org/jira/browse/CALCITE-3351
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.19.0
> Environment: Happened on both Windows and MacOS.
>Reporter: cui
>Priority: Major
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Exception was thrown when connecting with mySQL to query Chinese. The
> following SQL was executed:
> select * from \"test\".\"score_new\" where \"name\"= \'催\' limit 1
> ，if change "getDefaultCharset" in "RelDataTypeFactoryImpl" to
> return Charset.forName("UTF8");
> there will be also exception thrown as the following:
> java.sql.SQLException: Error while executing SQL "select * from
> "test"."score_new" where "name"= '催' limit 1": While executing SQL [SELECT
> *java.sql.SQLException: Error while executing SQL "select * from
> "test"."score_new" where "name"= '催' limit 1": While executing SQL [SELECT
> *FROM `score_new`WHERE `name` = u&'\50ac'LIMIT 1] on JDBC sub-schema at
> org.apache.calcite.avatica.Helper.createException(Helper.java:56) at
> org.apache.calcite.avatica.Helper.createException(Helper.java:41) at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:163)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:227)
> at QueryMysql.main(QueryMysql.java:42)Caused by: java.lang.RuntimeException:
> While executing SQL [SELECT *FROM `score_new`WHERE `name` = u&'\50ac'
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (CALCITE-3351) calcite mysql utf8 throws exception in Chinese
[
https://issues.apache.org/jira/browse/CALCITE-3351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rui Wang updated CALCITE-3351:
--
Description:
Exception was thrown when connecting with mySQL to query Chinese. The following
SQL was executed:
select * from \"test\".\"score_new\" where \"name\"= \'催\' limit 1
，if change "getDefaultCharset" in "RelDataTypeFactoryImpl" to
return Charset.forName("UTF8");
there will be also exception thrown as the following:
java.sql.SQLException: Error while executing SQL "select * from
"test"."score_new" where "name"= '催' limit 1": While executing SQL [SELECT
*java.sql.SQLException: Error while executing SQL "select * from
"test"."score_new" where "name"= '催' limit 1": While executing SQL [SELECT
*FROM `score_new`WHERE `name` = u&'\50ac'LIMIT 1] on JDBC sub-schema at
org.apache.calcite.avatica.Helper.createException(Helper.java:56) at
org.apache.calcite.avatica.Helper.createException(Helper.java:41) at
org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:163)
at
org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:227)
at QueryMysql.main(QueryMysql.java:42)Caused by: java.lang.RuntimeException:
While executing SQL [SELECT *FROM `score_new`WHERE `name` = u&'\50ac'
was:
发现连接mysql进行中文查询时候，执行这条sql：
select * from \"test\".\"score_new\" where \"name\"= \'催\' limit 1报错
，后来修改了RelDataTypeFactoryImpl的
getDefaultCharset方法为
return Charset.forName("UTF8");
还是报错，报错如下：
java.sql.SQLException: Error while executing SQL "select * from
"test"."score_new" where "name"= '催' limit 1": While executing SQL [SELECT
*java.sql.SQLException: Error while executing SQL "select * from
"test"."score_new" where "name"= '催' limit 1": While executing SQL [SELECT
*FROM `score_new`WHERE `name` = u&'\50ac'LIMIT 1] on JDBC sub-schema at
org.apache.calcite.avatica.Helper.createException(Helper.java:56) at
org.apache.calcite.avatica.Helper.createException(Helper.java:41) at
org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:163)
at
org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:227)
at QueryMysql.main(QueryMysql.java:42)Caused by: java.lang.RuntimeException:
While executing SQL [SELECT *FROM `score_new`WHERE `name` = u&'\50ac'
> calcite mysql utf8 throws exception in Chinese
> --
>
> Key: CALCITE-3351
> URL: https://issues.apache.org/jira/browse/CALCITE-3351
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.19.0
> Environment: Happened on both Windows and MacOS.
>Reporter: cui
>Priority: Major
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Exception was thrown when connecting with mySQL to query Chinese. The
> following SQL was executed:
> select * from \"test\".\"score_new\" where \"name\"= \'催\' limit 1
> ，if change "getDefaultCharset" in "RelDataTypeFactoryImpl" to
> return Charset.forName("UTF8");
> there will be also exception thrown as the following:
> java.sql.SQLException: Error while executing SQL "select * from
> "test"."score_new" where "name"= '催' limit 1": While executing SQL [SELECT
> *java.sql.SQLException: Error while executing SQL "select * from
> "test"."score_new" where "name"= '催' limit 1": While executing SQL [SELECT
> *FROM `score_new`WHERE `name` = u&'\50ac'LIMIT 1] on JDBC sub-schema at
> org.apache.calcite.avatica.Helper.createException(Helper.java:56) at
> org.apache.calcite.avatica.Helper.createException(Helper.java:41) at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:163)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:227)
> at QueryMysql.main(QueryMysql.java:42)Caused by: java.lang.RuntimeException:
> While executing SQL [SELECT *FROM `score_new`WHERE `name` = u&'\50ac'
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (CALCITE-3351) calcite mysql utf8 throws exception in Chinese
[
https://issues.apache.org/jira/browse/CALCITE-3351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rui Wang updated CALCITE-3351:
--
Environment: Happened on both Windows and MacOS. (was:
无论是windows还是mac，都会出同样的错误)
> calcite mysql utf8 throws exception in Chinese
> --
>
> Key: CALCITE-3351
> URL: https://issues.apache.org/jira/browse/CALCITE-3351
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.19.0
> Environment: Happened on both Windows and MacOS.
>Reporter: cui
>Priority: Major
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> 发现连接mysql进行中文查询时候，执行这条sql：
> select * from \"test\".\"score_new\" where \"name\"= \'催\' limit 1报错
> ，后来修改了RelDataTypeFactoryImpl的
> getDefaultCharset方法为
> return Charset.forName("UTF8");
> 还是报错，报错如下：
> java.sql.SQLException: Error while executing SQL "select * from
> "test"."score_new" where "name"= '催' limit 1": While executing SQL [SELECT
> *java.sql.SQLException: Error while executing SQL "select * from
> "test"."score_new" where "name"= '催' limit 1": While executing SQL [SELECT
> *FROM `score_new`WHERE `name` = u&'\50ac'LIMIT 1] on JDBC sub-schema at
> org.apache.calcite.avatica.Helper.createException(Helper.java:56) at
> org.apache.calcite.avatica.Helper.createException(Helper.java:41) at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:163)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:227)
> at QueryMysql.main(QueryMysql.java:42)Caused by: java.lang.RuntimeException:
> While executing SQL [SELECT *FROM `score_new`WHERE `name` = u&'\50ac'
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (CALCITE-3351) calcite mysql utf8 throws exception in Chinese
[
https://issues.apache.org/jira/browse/CALCITE-3351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rui Wang updated CALCITE-3351:
--
Summary: calcite mysql utf8 throws exception in Chinese (was: calcite
mysql utf8中文查询报错)
> calcite mysql utf8 throws exception in Chinese
> --
>
> Key: CALCITE-3351
> URL: https://issues.apache.org/jira/browse/CALCITE-3351
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.19.0
> Environment: 无论是windows还是mac，都会出同样的错误
>Reporter: cui
>Priority: Major
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> 发现连接mysql进行中文查询时候，执行这条sql：
> select * from \"test\".\"score_new\" where \"name\"= \'催\' limit 1报错
> ，后来修改了RelDataTypeFactoryImpl的
> getDefaultCharset方法为
> return Charset.forName("UTF8");
> 还是报错，报错如下：
> java.sql.SQLException: Error while executing SQL "select * from
> "test"."score_new" where "name"= '催' limit 1": While executing SQL [SELECT
> *java.sql.SQLException: Error while executing SQL "select * from
> "test"."score_new" where "name"= '催' limit 1": While executing SQL [SELECT
> *FROM `score_new`WHERE `name` = u&'\50ac'LIMIT 1] on JDBC sub-schema at
> org.apache.calcite.avatica.Helper.createException(Helper.java:56) at
> org.apache.calcite.avatica.Helper.createException(Helper.java:41) at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:163)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:227)
> at QueryMysql.main(QueryMysql.java:42)Caused by: java.lang.RuntimeException:
> While executing SQL [SELECT *FROM `score_new`WHERE `name` = u&'\50ac'
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Created] (CALCITE-3351) calcite mysql utf8中文查询报错
cui created CALCITE-3351:
Summary: calcite mysql utf8中文查询报错
Key: CALCITE-3351
URL: https://issues.apache.org/jira/browse/CALCITE-3351
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.19.0
Environment: 无论是windows还是mac，都会出同样的错误
Reporter: cui
发现连接mysql进行中文查询时候，执行这条sql：
select * from \"test\".\"score_new\" where \"name\"= \'催\' limit 1报错
，后来修改了RelDataTypeFactoryImpl的
getDefaultCharset方法为
return Charset.forName("UTF8");
还是报错，报错如下：
java.sql.SQLException: Error while executing SQL "select * from
"test"."score_new" where "name"= '催' limit 1": While executing SQL [SELECT
*java.sql.SQLException: Error while executing SQL "select * from
"test"."score_new" where "name"= '催' limit 1": While executing SQL [SELECT
*FROM `score_new`WHERE `name` = u&'\50ac'LIMIT 1] on JDBC sub-schema at
org.apache.calcite.avatica.Helper.createException(Helper.java:56) at
org.apache.calcite.avatica.Helper.createException(Helper.java:41) at
org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:163)
at
org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:227)
at QueryMysql.main(QueryMysql.java:42)Caused by: java.lang.RuntimeException:
While executing SQL [SELECT *FROM `score_new`WHERE `name` = u&'\50ac'
--
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=16930535#comment-16930535 ] jin xing commented on CALCITE-3334: --- Thanks for comment [~lishuming] I raised a PR as above and started a discussion thread [on d...@calcite.apache.org|mailto:on%c2%a0...@calcite.apache.org] -- "[DISCUSS] Refinement for Substitution-Based MV Matching" and hope to get more comments. Gentle ping [~julianhyde] [~jcamachorodriguez] [~swtalbot] [~maryannxue] It's great if you can give some advice when you have time. Thus I can know if I'm on the right direction. Best, Jin > 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: 0.5h > 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] [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
]
ASF GitHub Bot updated CALCITE-3350:
Labels: pull-request-available (was: )
> 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
> Labels: pull-request-available
>
> 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] [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] [Commented] (CALCITE-3349) Add Function DDL into SqlKind DDL enum
[ https://issues.apache.org/jira/browse/CALCITE-3349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16930486#comment-16930486 ] ShuMing Li commented on CALCITE-3349: - Just be curious, `SqlCreateFunction` is not implemented of `SqlExecutableStatement`, maybe throw exceptions when `executeDdl`. > Add Function DDL into SqlKind DDL enum > -- > > Key: CALCITE-3349 > URL: https://issues.apache.org/jira/browse/CALCITE-3349 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Zhenqiu Huang >Priority: Minor > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > Currently, Create Function, Drop Function are not added into SqlKind DDL > enum. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (CALCITE-2772) Support varargs for user-defined functions (UDFs)
[
https://issues.apache.org/jira/browse/CALCITE-2772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16930469#comment-16930469
]
Stamatis Zampetakis commented on CALCITE-2772:
--
Thanks for looking into this [~danny0405]. Sorry but I did not understand what
you mean by saying _breaking change_. Do you refer to the approach in general
or the particular implementation in the PR?
> Support varargs for user-defined functions (UDFs)
> -
>
> Key: CALCITE-2772
> URL: https://issues.apache.org/jira/browse/CALCITE-2772
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: pengzhiwei
>Assignee: pengzhiwei
>Priority: Major
> Labels: pull-request-available
> Attachments: support_varargs_udf.patch
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Support varargs for user-defined functions as the case followed:
> {code:java}
> public class ConcatWs {
> public String eval(String sep, String... strs) {...}
> }{code}
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Resolved] (CALCITE-3282) HiveSqlDialect unparse Interger type as Int in order to be compatible with Hive1.x
[ https://issues.apache.org/jira/browse/CALCITE-3282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danny Chan resolved CALCITE-3282. - Fix Version/s: 1.22.0 Assignee: Danny Chan Resolution: Fixed Fixed in [148bfd3|https://github.com/apache/calcite/commit/148bfd329413c0272395cc0b7c322b3c5a34b667], thanks for your PR, [~ffmax] ! > HiveSqlDialect unparse Interger type as Int in order to be compatible with > Hive1.x > -- > > Key: CALCITE-3282 > URL: https://issues.apache.org/jira/browse/CALCITE-3282 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: feng huang >Assignee: Danny Chan >Priority: Minor > Labels: pull-request-available > Fix For: 1.22.0 > > Time Spent: 2.5h > Remaining Estimate: 0h > > Every database might have different type or same type but different type > name, therefore making every SqlDialect unparse their own data type is a > suitable way. > For example, there is a sql “select cast(col as int) from table” change to > hive sql "select cast(col as integer) from table", but "integer" is not > allowed in hive. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (CALCITE-3282) HiveSqlDialect unparse Interger type as Int in order to be compatible with Hive1.x
[ https://issues.apache.org/jira/browse/CALCITE-3282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danny Chan updated CALCITE-3282: Summary: HiveSqlDialect unparse Interger type as Int in order to be compatible with Hive1.x (was: Make every SqlDialect unparse their own data type) > HiveSqlDialect unparse Interger type as Int in order to be compatible with > Hive1.x > -- > > Key: CALCITE-3282 > URL: https://issues.apache.org/jira/browse/CALCITE-3282 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: feng huang >Priority: Minor > Labels: pull-request-available > Time Spent: 2h 20m > Remaining Estimate: 0h > > Every database might have different type or same type but different type > name, therefore making every SqlDialect unparse their own data type is a > suitable way. > For example, there is a sql “select cast(col as int) from table” change to > hive sql "select cast(col as integer) from table", but "integer" is not > allowed in hive. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (CALCITE-2166) Cumulative cost of RelSubset.best RelNode is increased after calling RelSubset.propagateCostImprovements() for input RelNodes
[
https://issues.apache.org/jira/browse/CALCITE-2166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16930395#comment-16930395
]
Xiening Dai commented on CALCITE-2166:
--
hi [~danny0405], sorry I just saw your comments here in JIRA. The reason I
chose #2 is because with #1 we would possibly get into the other error "rel x
has lower cost than the best of subset", which is the problem we tried to fix
in the first place. #2 pay slightly higher cost but does guarantee we have the
cheapest rel in subset as the best rel. There are multiple places broken in the
memo we need to fix them one by one. I agree 2018 is more fundamental, and
personally I prefer get that fixed first. But the previous consensus was to fix
2166 first.
> Cumulative cost of RelSubset.best RelNode is increased after calling
> RelSubset.propagateCostImprovements() for input RelNodes
> -
>
> Key: CALCITE-2166
> URL: https://issues.apache.org/jira/browse/CALCITE-2166
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.15.0
>Reporter: Volodymyr Vysotskyi
>Assignee: Danny Chan
>Priority: Critical
> Labels: pull-request-available
> Fix For: 1.22.0
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> After calling {{RelSubset.propagateCostImprovements()}} cumulative cost of
> {{RelSubset.best}} {{RelNode}} may be increased due to the increase of the
> non-cumulative cost caused by changing of input best {{RelNode}}.
> To observe this issue, add this code:
> {code:java}
> if (subset.best != null) {
> RelOptCost bestCost = getCost(subset.best,
> RelMetadataQuery.instance());
> if (!subset.bestCost.equals(bestCost)) {
> throw new AssertionError(
> "relSubset [" + subset.getDescription()
> + "] has wrong best cost "
> + subset.bestCost + ". Correct cost is " + bestCost);
> }
> }
> {code}
> into {{VolcanoPlanner.validate()}} method (line 907).
> List of unit tests which fail with this check:
> {noformat}
> Failed tests:
>
> MaterializationTest.testJoinMaterializationUKFK9:1823->checkMaterialize:198->checkMaterialize:205->checkThatMaterialize:233
> relSubset [rel#226287:Subset#8.ENUMERABLE.[]] has wrong best cost {221.5
> rows, 128.25 cpu, 0.0 io}. Correct cost is {233.0 rows, 178.0 cpu, 0.0 io}
> ScannableTableTest.testPFPushDownProjectFilterAggregateNested:279 relSubset
> [rel#12950:Subset#5.ENUMERABLE.[]] has wrong best cost {63.8 rows, 62.308
> cpu, 0.0 io}. Correct cost is {70.4 rows, 60.404 cpu, 0.0 io}
> ScannableTableTest.testPFTableRefusesFilterCooperative:221 relSubset
> [rel#13382:Subset#2.ENUMERABLE.[]] has wrong best cost {81.0 rows, 181.01
> cpu, 0.0 io}. Correct cost is {150.5 rows, 250.505 cpu, 0.0 io}
> ScannableTableTest.testProjectableFilterableCooperative:148 relSubset
> [rel#13611:Subset#2.ENUMERABLE.[]] has wrong best cost {81.0 rows, 181.01
> cpu, 0.0 io}. Correct cost is {150.5 rows, 250.505 cpu, 0.0 io}
> ScannableTableTest.testProjectableFilterableNonCooperative:165 relSubset
> [rel#13754:Subset#2.ENUMERABLE.[]] has wrong best cost {81.0 rows, 181.01
> cpu, 0.0 io}. Correct cost is {150.5 rows, 250.505 cpu, 0.0 io}
> FrameworksTest.testUpdate:336->executeQuery:367 relSubset
> [rel#22533:Subset#2.ENUMERABLE.any] has wrong best cost {19.5 rows, 37.75
> cpu, 0.0 io}. Correct cost is {22.575 rows, 52.58 cpu, 0.0 io}
> {noformat}
> For the test {{MaterializationTest.testJoinMaterializationUKFK9}} initial
> best plan was:
> {noformat}
> EnumerableProject(empid0=[$5], empid00=[$5], deptno0=[$7]): rowcount = 15.0,
> cumulative cost = {15.0 rows, 45.0 cpu, 0.0 io}, id = 3989
> EnumerableJoin(subset=[rel#3988:Subset#34.ENUMERABLE.[]], condition=[=($1,
> $7)], joinType=[inner]): rowcount = 15.0, cumulative cost = {116.0 rows, 0.0
> cpu, 0.0 io}, id = 4797
> EnumerableFilter(subset=[rel#4274:Subset#47.ENUMERABLE.[0]],
> condition=[=(CAST($2):VARCHAR CHARACTER SET "ISO-8859-1" COLLATE
> "ISO-8859-1$en_US$primary", 'Bill')]): rowcount = 1.0, cumulative cost = {1.0
> rows, 1.0 cpu, 0.0 io}, id = 16522
> EnumerableTableScan(subset=[rel#158:Subset#11.ENUMERABLE.[0]],
> table=[[hr, m0]]): rowcount = 1.0, cumulative cost = {0.0 rows, 1.0 cpu, 0.0
> io}, id = 79
> EnumerableTableScan(subset=[rel#115:Subset#5.ENUMERABLE.[]], table=[[hr,
> depts]]): rowcount = 100.0, cumulative cost = {100.0 rows, 101.0 cpu, 0.0
> io}, id = 62
> {noformat}
> Its cumulative cost is \{221.5 rows, 123.75 cpu, 0.0 io}
> After applying some rules it became:
> {noformat}
> EnumerableProject(empid0=[$3], empid00=[$3], deptno0=[$0
[jira] [Commented] (CALCITE-2772) Support varargs for user-defined functions (UDFs)
[
https://issues.apache.org/jira/browse/CALCITE-2772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16930393#comment-16930393
]
Danny Chan commented on CALCITE-2772:
-
The change is breaking, because the user defined function are user api, we
should be cautious if we really need the arguments to be variable.
> Support varargs for user-defined functions (UDFs)
> -
>
> Key: CALCITE-2772
> URL: https://issues.apache.org/jira/browse/CALCITE-2772
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: pengzhiwei
>Assignee: pengzhiwei
>Priority: Major
> Labels: pull-request-available
> Attachments: support_varargs_udf.patch
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Support varargs for user-defined functions as the case followed:
> {code:java}
> public class ConcatWs {
> public String eval(String sep, String... strs) {...}
> }{code}
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (CALCITE-2772) Support varargs for user-defined functions (UDFs)
[
https://issues.apache.org/jira/browse/CALCITE-2772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16930390#comment-16930390
]
Danny Chan commented on CALCITE-2772:
-
Let me repeat the review comments again:
Before the review start, can you share your cases why we need to support
variable arguments for UDF/UDAF/UDTF ? We have already declare multiple number
of arguments when registering the functions into the catalog.
For example, we can declare both my_udf(string, string) and my_udf(string,
string, string), so do we really need to support freely variable length
argument functions ?
> Support varargs for user-defined functions (UDFs)
> -
>
> Key: CALCITE-2772
> URL: https://issues.apache.org/jira/browse/CALCITE-2772
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: pengzhiwei
>Assignee: pengzhiwei
>Priority: Major
> Labels: pull-request-available
> Attachments: support_varargs_udf.patch
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Support varargs for user-defined functions as the case followed:
> {code:java}
> public class ConcatWs {
> public String eval(String sep, String... strs) {...}
> }{code}
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[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] [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] [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
