[jira] [Commented] (CALCITE-3929) NullPointerException when deserialize UDAF aggregate call from json string
[
https://issues.apache.org/jira/browse/CALCITE-3929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17084535#comment-17084535
]
Wang Yanlin commented on CALCITE-3929:
--
[~wojustme], OK, thanks for working on this.
> NullPointerException when deserialize UDAF aggregate call from json string
> --
>
> Key: CALCITE-3929
> URL: https://issues.apache.org/jira/browse/CALCITE-3929
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Major
>
> When serialize a relation algebra which contains udaf aggregate call, it
> works well and get the json string.
> But when deserialize from the json string, got NullPointerException as below
> {noformat}
> java.lang.RuntimeException: java.lang.NullPointerException
> at org.apache.calcite.tools.Frameworks.withPrepare(Frameworks.java:182)
> at org.apache.calcite.tools.Frameworks.withPlanner(Frameworks.java:126)
> at org.apache.calcite.tools.Frameworks.withPlanner(Frameworks.java:144)
> at
> org.apache.calcite.plan.RelWriterTest.deserializeAndDumpToTextFormat(RelWriterTest.java:828)
> at
> org.apache.calcite.plan.RelWriterTest.testUDAF(RelWriterTest.java:921)
> 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(ExecutableInvoker.java:98)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$6(TestMethodTestDescriptor.java:202)
> at
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:198)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:135)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:69)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$5(NodeTestTask.java:135)
> at
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$7(NodeTestTask.java:125)
> at
> org.junit.platform.engine.support.hierarchical.Node.around(Node.java:135)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:123)
> at
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:122)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:80)
> at java.util.ArrayList.forEach(ArrayList.java:1257)
> at
>
[jira] [Resolved] (CALCITE-3895) When the group sets of Aggregate is not null, union of its members should contain group key
[
https://issues.apache.org/jira/browse/CALCITE-3895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Feng Zhu resolved CALCITE-3895.
---
Resolution: Not A Problem
> When the group sets of Aggregate is not null, union of its members should
> contain group key
> ---
>
> Key: CALCITE-3895
> URL: https://issues.apache.org/jira/browse/CALCITE-3895
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.22.0
>Reporter: Feng Zhu
>Assignee: Feng Zhu
>Priority: Major
> Fix For: 1.23.0
>
>
> In general, the following query will fail in validation phase with “deptno
> is not being grouped”.
> {code:java}
> select deptno, count(*) as c
> from emp
> group by grouping sets (())
> {code}
> However, there is no constraint in Aggregate. For example, we can still
> create the RelNode by RelBuilder.
> {code:java}
> @Test void testAggregate6() {
> // Equivalent SQL (illegal):
> // SELECT deptno, count(*) AS C
> // FROM emp
> // GROUP BY grouping sets (())
> final RelBuilder builder = RelBuilder.create(config().build());
> RelNode aggregate = builder.scan("EMP")
> .aggregate(
> builder.groupKey(ImmutableBitSet.of(0),
> (Iterable) ImmutableList.of(
> ImmutableBitSet.of())),
> builder.countStar("C"))
> .build();
> });
> }
> {code}
> It is interesting that the rutime can process illegal RelNode and return
> result as expected.
> This issue is exposed in CALCITE-3893. However, we can also find the same
> case in _*RelMetadataTest#checkAverageRowSize*_. So I opened an individual
> Jira to discuss it.
> I propose to add the constraint below: assert
> {code:java}
> ImmutableBitSet.union(groupSets).contains(groupSet)
> : "the union of group sets should contain group key";
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CALCITE-3893) SQL with GROUP_ID may generate wrong plan
[
https://issues.apache.org/jira/browse/CALCITE-3893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Feng Zhu resolved CALCITE-3893.
---
Resolution: Not A Problem
> SQL with GROUP_ID may generate wrong plan
> -
>
> Key: CALCITE-3893
> URL: https://issues.apache.org/jira/browse/CALCITE-3893
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.22.0
>Reporter: Shuo Cheng
>Assignee: Feng Zhu
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.23.0
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> Consider the following SQL:
> {code:java}
> select
> deptno, group_id() as g, count(*) as c
> from emp
> group by grouping sets (deptno, (), ())
> {code}
> the plan after SqlToRel is:
> {code:java}
> LogicalUnion(all=[true])
> LogicalProject(DEPTNO=[$0], G=[0:BIGINT], C=[$1])
> LogicalAggregate(group=[{0}], groups=[[{0}, {}]], C=[COUNT()])
> LogicalProject(DEPTNO=[$7])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalProject(DEPTNO=[$0], G=[1:BIGINT], C=[$1])
> LogicalAggregate(group=[{0}], groups=[[{}]], C=[COUNT()])
> LogicalProject(DEPTNO=[$7])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> {code}
> I'm afraid there's some semantic problems here. As `groups` of the second
> Aggregate is empty, then what is `$0` meaning in the Project above it. Maybe
> that we want is:
> {code:java}
> LogicalUnion(all=[true])
> LogicalProject(DEPTNO=[$0], G=[0:BIGINT], C=[$1])
> LogicalAggregate(group=[{0}], groups=[[{0}, {}]], C=[COUNT()])
> LogicalProject(DEPTNO=[$7])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalProject(DEPTNO=[$0], G=[1:BIGINT], C=[$1])
> LogicalAggregate(group=[{0}], groups=[[{0}]], C=[COUNT()])
> LogicalProject(DEPTNO=[null])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]]){code}
> I noticed this is introduced by CALCITE-1824, cc [~donnyzone],
> [~vladimirsitnikov].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-3930) When converting Aggregate to SQL, add Having clause if a group key is not in group sets
Feng Zhu created CALCITE-3930:
-
Summary: When converting Aggregate to SQL, add Having clause if a
group key is not in group sets
Key: CALCITE-3930
URL: https://issues.apache.org/jira/browse/CALCITE-3930
Project: Calcite
Issue Type: Bug
Components: core
Reporter: Feng Zhu
According to the discussion in CALCITE-3893 and CALCITE-3895, RelNode below is
allowed in Calcite.
{code:java}
final RelBuilder builder = RelBuilder.create(config().build());
RelNode aggregate = builder.scan("EMP")
.aggregate(
builder.groupKey(ImmutableBitSet.of(0),
(Iterable) ImmutableList.of(
ImmutableBitSet.of())),
builder.countStar("C"))
.build();
});
LogicalAggregate(group=[{0}], groups=[[{}]], C=[COUNT()])
{code}
But the SQL is not correct ('deptno is not being grouped').
{code:java}
SELECT deptno, count(*) AS C
FROM emp
GROUP BY grouping sets (())
{code}
We need to address such cases.
{code:java}
SELECT deptno, count(*) AS C
FROM emp
GROUP BY grouping sets (deptno,())
Having GROUPING_ID(deptno) = 1
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3928) Canonicalization doesn't do field trimming before materialized view matching
[
https://issues.apache.org/jira/browse/CALCITE-3928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17084527#comment-17084527
]
Danny Chen commented on CALCITE-3928:
-
The title is really hard to understand, maybe we can try to describe in the SQL
way, use the SQL keywords.
> Canonicalization doesn't do field trimming before materialized view matching
>
>
> Key: CALCITE-3928
> URL: https://issues.apache.org/jira/browse/CALCITE-3928
> Project: Calcite
> Issue Type: Bug
>Reporter: Jin Xing
>Priority: Major
>
> If we have query and materialized view as below:
> {code:java}
> query:
> LogicalAggregate(group=[{0}], EXPR$1=[afunc($1, $1)])
> LogicalProject(a=$0, b=[bfunc($1)])
> LogicalTableScan(table=[[default, user_table]])
> mv:
> LogicalAggregate(group=[{0}], EXPR$1=[afunc($1, $2)])
> LogicalProject(a=$0, b=[bfunc($1)], c=[bfunc($1)])
> LogicalTableScan(table=[[default, user_table]])
> {code}
> The semantics of query and mv logic are the same. Materialized view matching
> failed, because field trimming is not done when canonicalizing the plans.
> Currently Calcite does field trimming when convert sql to rel. But my
> company's internal system does materialization detection – – generates &
> transforms & stores the RelNode.
> Shall we add the field trimming when canonicalizing materialized view logic?
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3929) NullPointerException when deserialize UDAF aggregate call from json string
[
https://issues.apache.org/jira/browse/CALCITE-3929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17084525#comment-17084525
]
Danny Chen commented on CALCITE-3929:
-
Thanks [~wojustme] for engage in, you can send a mail to DEV mailing list, show
you JIRA ID, and we can assign the JIRA contribution permission to you, until
then, you can assign the issue by your self.
> NullPointerException when deserialize UDAF aggregate call from json string
> --
>
> Key: CALCITE-3929
> URL: https://issues.apache.org/jira/browse/CALCITE-3929
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Major
>
> When serialize a relation algebra which contains udaf aggregate call, it
> works well and get the json string.
> But when deserialize from the json string, got NullPointerException as below
> {noformat}
> java.lang.RuntimeException: java.lang.NullPointerException
> at org.apache.calcite.tools.Frameworks.withPrepare(Frameworks.java:182)
> at org.apache.calcite.tools.Frameworks.withPlanner(Frameworks.java:126)
> at org.apache.calcite.tools.Frameworks.withPlanner(Frameworks.java:144)
> at
> org.apache.calcite.plan.RelWriterTest.deserializeAndDumpToTextFormat(RelWriterTest.java:828)
> at
> org.apache.calcite.plan.RelWriterTest.testUDAF(RelWriterTest.java:921)
> 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(ExecutableInvoker.java:98)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$6(TestMethodTestDescriptor.java:202)
> at
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:198)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:135)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:69)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$5(NodeTestTask.java:135)
> at
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$7(NodeTestTask.java:125)
> at
> org.junit.platform.engine.support.hierarchical.Node.around(Node.java:135)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:123)
> at
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:122)
> at
>
[jira] [Comment Edited] (CALCITE-3894) The Union operation between DATE with TIMESTAMP returns a wrong result
[
https://issues.apache.org/jira/browse/CALCITE-3894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17084520#comment-17084520
]
Danny Chen edited comment on CALCITE-3894 at 4/16/20, 4:10 AM:
---
Finally i got the reason:
The RelDataTypeFactory#leastRestrictive finds the common type for IN,
CASE and SET operations. For common type with DATE and TIMESTAMP, it
returns DATE. The root cause is that rules in SqlTypeAssignmentRule
decide that DATE is assignable from TIMESTAMP, which is actually wrong.
Although in Java, this assignment makes sense but that
does not mean it's true in SQL, because DATE and TIMESTAMP have different time
unit.
Fix the rules in SqlTypeAssignmentRule and let the implicit type
coercion rule get involved.
was (Author: danny0405):
Finally i got the reason:
The RelDataTypeFactory#leastRestrictive finds the common type for IN, CASE and
SET operations. For common type with DATE and TIMESTAMP, it returns DATE. The
root cause is that rules in SqlTypeAssignmentRule decide that DATE is
assignable from TIMESTAMP and TIMESTAMP is assignable from DATE, which is
actually wrong. Although in Java, this assignment makes sense but that does not
mean it's true in SQL, because DATE and TIMESTAMP have different time unit.
> The Union operation between DATE with TIMESTAMP returns a wrong result
> --
>
> Key: CALCITE-3894
> URL: https://issues.apache.org/jira/browse/CALCITE-3894
> Project: Calcite
> Issue Type: Bug
>Reporter: TANG Wen-hui
>Assignee: TANG Wen-hui
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code:java}
> @Test public void testUnionTime() {
> CalciteAssert.AssertThat assertThat = CalciteAssert.that();
> String query = "select * from (\n"
> + "select \"id\" from (VALUES(DATE '2018-02-03')) \"foo\"(\"id\")\n"
> + "union\n"
> + "select \"id\" from (VALUES(TIMESTAMP '2008-03-31 12:23:34'))
> \"foo\"(\"id\"))";
> assertThat.query(query).returns("id=2108-03-12\nid=2018-02-03\n");
> }{code}
> The test with wrong result passed.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3894) The Union operation between DATE with TIMESTAMP returns a wrong result
[
https://issues.apache.org/jira/browse/CALCITE-3894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-3894:
Labels: pull-request-available (was: )
> The Union operation between DATE with TIMESTAMP returns a wrong result
> --
>
> Key: CALCITE-3894
> URL: https://issues.apache.org/jira/browse/CALCITE-3894
> Project: Calcite
> Issue Type: Bug
>Reporter: TANG Wen-hui
>Assignee: TANG Wen-hui
>Priority: Major
> Labels: pull-request-available
>
> {code:java}
> @Test public void testUnionTime() {
> CalciteAssert.AssertThat assertThat = CalciteAssert.that();
> String query = "select * from (\n"
> + "select \"id\" from (VALUES(DATE '2018-02-03')) \"foo\"(\"id\")\n"
> + "union\n"
> + "select \"id\" from (VALUES(TIMESTAMP '2008-03-31 12:23:34'))
> \"foo\"(\"id\"))";
> assertThat.query(query).returns("id=2108-03-12\nid=2018-02-03\n");
> }{code}
> The test with wrong result passed.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3894) The Union operation between DATE with TIMESTAMP returns a wrong result
[
https://issues.apache.org/jira/browse/CALCITE-3894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17084520#comment-17084520
]
Danny Chen commented on CALCITE-3894:
-
Finally i got the reason:
The RelDataTypeFactory#leastRestrictive finds the common type for IN, CASE and
SET operations. For common type with DATE and TIMESTAMP, it returns DATE. The
root cause is that rules in SqlTypeAssignmentRule decide that DATE is
assignable from TIMESTAMP and TIMESTAMP is assignable from DATE, which is
actually wrong. Although in Java, this assignment makes sense but that does not
mean it's true in SQL, because DATE and TIMESTAMP have different time unit.
> The Union operation between DATE with TIMESTAMP returns a wrong result
> --
>
> Key: CALCITE-3894
> URL: https://issues.apache.org/jira/browse/CALCITE-3894
> Project: Calcite
> Issue Type: Bug
>Reporter: TANG Wen-hui
>Assignee: TANG Wen-hui
>Priority: Major
>
> {code:java}
> @Test public void testUnionTime() {
> CalciteAssert.AssertThat assertThat = CalciteAssert.that();
> String query = "select * from (\n"
> + "select \"id\" from (VALUES(DATE '2018-02-03')) \"foo\"(\"id\")\n"
> + "union\n"
> + "select \"id\" from (VALUES(TIMESTAMP '2008-03-31 12:23:34'))
> \"foo\"(\"id\"))";
> assertThat.query(query).returns("id=2108-03-12\nid=2018-02-03\n");
> }{code}
> The test with wrong result passed.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3929) NullPointerException when deserialize UDAF aggregate call from json string
[
https://issues.apache.org/jira/browse/CALCITE-3929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17084517#comment-17084517
]
Xurenhe commented on CALCITE-3929:
--
Hi [~yanlin-Lynn]
I'm interested in this issue, can you arrange for me?
> NullPointerException when deserialize UDAF aggregate call from json string
> --
>
> Key: CALCITE-3929
> URL: https://issues.apache.org/jira/browse/CALCITE-3929
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Major
>
> When serialize a relation algebra which contains udaf aggregate call, it
> works well and get the json string.
> But when deserialize from the json string, got NullPointerException as below
> {noformat}
> java.lang.RuntimeException: java.lang.NullPointerException
> at org.apache.calcite.tools.Frameworks.withPrepare(Frameworks.java:182)
> at org.apache.calcite.tools.Frameworks.withPlanner(Frameworks.java:126)
> at org.apache.calcite.tools.Frameworks.withPlanner(Frameworks.java:144)
> at
> org.apache.calcite.plan.RelWriterTest.deserializeAndDumpToTextFormat(RelWriterTest.java:828)
> at
> org.apache.calcite.plan.RelWriterTest.testUDAF(RelWriterTest.java:921)
> 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(ExecutableInvoker.java:98)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$6(TestMethodTestDescriptor.java:202)
> at
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:198)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:135)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:69)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$5(NodeTestTask.java:135)
> at
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$7(NodeTestTask.java:125)
> at
> org.junit.platform.engine.support.hierarchical.Node.around(Node.java:135)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:123)
> at
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:122)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:80)
> at java.util.ArrayList.forEach(ArrayList.java:1257)
> at
>
[jira] [Assigned] (CALCITE-3929) NullPointerException when deserialize UDAF aggregate call from json string
[
https://issues.apache.org/jira/browse/CALCITE-3929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin reassigned CALCITE-3929:
Assignee: Wang Yanlin
> NullPointerException when deserialize UDAF aggregate call from json string
> --
>
> Key: CALCITE-3929
> URL: https://issues.apache.org/jira/browse/CALCITE-3929
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Major
>
> When serialize a relation algebra which contains udaf aggregate call, it
> works well and get the json string.
> But when deserialize from the json string, got NullPointerException as below
> {noformat}
> java.lang.RuntimeException: java.lang.NullPointerException
> at org.apache.calcite.tools.Frameworks.withPrepare(Frameworks.java:182)
> at org.apache.calcite.tools.Frameworks.withPlanner(Frameworks.java:126)
> at org.apache.calcite.tools.Frameworks.withPlanner(Frameworks.java:144)
> at
> org.apache.calcite.plan.RelWriterTest.deserializeAndDumpToTextFormat(RelWriterTest.java:828)
> at
> org.apache.calcite.plan.RelWriterTest.testUDAF(RelWriterTest.java:921)
> 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(ExecutableInvoker.java:98)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$6(TestMethodTestDescriptor.java:202)
> at
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:198)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:135)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:69)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$5(NodeTestTask.java:135)
> at
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$7(NodeTestTask.java:125)
> at
> org.junit.platform.engine.support.hierarchical.Node.around(Node.java:135)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:123)
> at
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:122)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:80)
> at java.util.ArrayList.forEach(ArrayList.java:1257)
> at
>
[jira] [Updated] (CALCITE-3928) Canonicalization doesn't do field trimming before materialized view matching
[
https://issues.apache.org/jira/browse/CALCITE-3928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jin Xing updated CALCITE-3928:
--
Summary: Canonicalization doesn't do field trimming before materialized
view matching (was: Canonicalization doesn't do field trimming before
materialized matching)
> Canonicalization doesn't do field trimming before materialized view matching
>
>
> Key: CALCITE-3928
> URL: https://issues.apache.org/jira/browse/CALCITE-3928
> Project: Calcite
> Issue Type: Bug
>Reporter: Jin Xing
>Priority: Major
>
> If we have query and materialized view as below:
> {code:java}
> query:
> LogicalAggregate(group=[{0}], EXPR$1=[afunc($1, $1)])
> LogicalProject(a=$0, b=[bfunc($1)])
> LogicalTableScan(table=[[default, user_table]])
> mv:
> LogicalAggregate(group=[{0}], EXPR$1=[afunc($1, $2)])
> LogicalProject(a=$0, b=[bfunc($1)], c=[bfunc($1)])
> LogicalTableScan(table=[[default, user_table]])
> {code}
> The semantics of query and mv logic are the same. Materialized view matching
> failed, because field trimming is not done when canonicalizing the plans.
> Currently Calcite does field trimming when convert sql to rel. But my
> company's internal system does materialization detection – – generates &
> transforms & stores the RelNode.
> Shall we add the field trimming when canonicalizing materialized view logic?
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-3929) NullPointerException when deserialize UDAF aggregate call from json string
Wang Yanlin created CALCITE-3929:
Summary: NullPointerException when deserialize UDAF aggregate call
from json string
Key: CALCITE-3929
URL: https://issues.apache.org/jira/browse/CALCITE-3929
Project: Calcite
Issue Type: Bug
Reporter: Wang Yanlin
When serialize a relation algebra which contains udaf aggregate call, it works
well and get the json string.
But when deserialize from the json string, got NullPointerException as below
{noformat}
java.lang.RuntimeException: java.lang.NullPointerException
at org.apache.calcite.tools.Frameworks.withPrepare(Frameworks.java:182)
at org.apache.calcite.tools.Frameworks.withPlanner(Frameworks.java:126)
at org.apache.calcite.tools.Frameworks.withPlanner(Frameworks.java:144)
at
org.apache.calcite.plan.RelWriterTest.deserializeAndDumpToTextFormat(RelWriterTest.java:828)
at
org.apache.calcite.plan.RelWriterTest.testUDAF(RelWriterTest.java:921)
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(ExecutableInvoker.java:98)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$6(TestMethodTestDescriptor.java:202)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:198)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:135)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:69)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$5(NodeTestTask.java:135)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$7(NodeTestTask.java:125)
at
org.junit.platform.engine.support.hierarchical.Node.around(Node.java:135)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:123)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:122)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:80)
at java.util.ArrayList.forEach(ArrayList.java:1257)
at
org.junit.platform.engine.support.hierarchical.SameThreadHierarchicalTestExecutorService.invokeAll(SameThreadHierarchicalTestExecutorService.java:38)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$5(NodeTestTask.java:139)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
[jira] [Updated] (CALCITE-3928) Canonicalization doesn't do field trimming before materialized matching
[
https://issues.apache.org/jira/browse/CALCITE-3928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jin Xing updated CALCITE-3928:
--
Description:
If we have query and materialized view as below:
{code:java}
query:
LogicalAggregate(group=[{0}], EXPR$1=[afunc($1, $1)])
LogicalProject(a=$0, b=[bfunc($1)])
LogicalTableScan(table=[[default, user_table]])
mv:
LogicalAggregate(group=[{0}], EXPR$1=[afunc($1, $2)])
LogicalProject(a=$0, b=[bfunc($1)], c=[bfunc($1)])
LogicalTableScan(table=[[default, user_table]])
{code}
The semantics of query and mv logic are the same. Materialized view matching
failed, because field trimming is not done when canonicalizing the plans.
Currently Calcite does field trimming when convert sql to rel. But my
company's internal system does materialization detection – – generates &
transforms & stores the RelNode.
Shall we add the field trimming when canonicalizing materialized view logic?
> Canonicalization doesn't do field trimming before materialized matching
> ---
>
> Key: CALCITE-3928
> URL: https://issues.apache.org/jira/browse/CALCITE-3928
> Project: Calcite
> Issue Type: Bug
>Reporter: Jin Xing
>Priority: Major
>
> If we have query and materialized view as below:
> {code:java}
> query:
> LogicalAggregate(group=[{0}], EXPR$1=[afunc($1, $1)])
> LogicalProject(a=$0, b=[bfunc($1)])
> LogicalTableScan(table=[[default, user_table]])
> mv:
> LogicalAggregate(group=[{0}], EXPR$1=[afunc($1, $2)])
> LogicalProject(a=$0, b=[bfunc($1)], c=[bfunc($1)])
> LogicalTableScan(table=[[default, user_table]])
> {code}
> The semantics of query and mv logic are the same. Materialized view matching
> failed, because field trimming is not done when canonicalizing the plans.
> Currently Calcite does field trimming when convert sql to rel. But my
> company's internal system does materialization detection – – generates &
> transforms & stores the RelNode.
> Shall we add the field trimming when canonicalizing materialized view logic?
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-3928) Canonicalization doesn't do field trimming before materialized matching
Jin Xing created CALCITE-3928: - Summary: Canonicalization doesn't do field trimming before materialized matching Key: CALCITE-3928 URL: https://issues.apache.org/jira/browse/CALCITE-3928 Project: Calcite Issue Type: Bug Reporter: Jin Xing -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3927) RelSubset is not fired for rule when set gets merged
[ https://issues.apache.org/jira/browse/CALCITE-3927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17084366#comment-17084366 ] Haisheng Yuan commented on CALCITE-3927: That might be challenging. [~botong] Any easy case? > RelSubset is not fired for rule when set gets merged > > > Key: CALCITE-3927 > URL: https://issues.apache.org/jira/browse/CALCITE-3927 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: Haisheng Yuan >Priority: Major > > In VolcanoPlanner, when set gets merged, planner fires rules again for > RelNodes in both sets, but not for RelSubset. We might miss something because > of this. > If all the logical transformation rules and physical implementation rules are > separated out in different stage and physical rules don't do logical work, we > might be OK. But the reality is that all the things are mixed together at the > moment. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3923) Refactor how planner rules are parameterized
[
https://issues.apache.org/jira/browse/CALCITE-3923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17084326#comment-17084326
]
Julian Hyde commented on CALCITE-3923:
--
I have created a prototype in my
[3923-rule-config|https://github.com/julianhyde/calcite/tree/3923-rule-config]
branch. Can some people review? Let's discuss.
> Refactor how planner rules are parameterized
>
>
> Key: CALCITE-3923
> URL: https://issues.apache.org/jira/browse/CALCITE-3923
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
>
> People often want different variants of planner rules. An example is
> {{FilterJoinRule}}, which has a 'boolean smart’ parameter, a predicate (which
> returns whether to pull up filter conditions), operands (which determine the
> precise sub-classes of {{RelNode}} that the rule should match) and a
> {{RelBuilderFactory}} (which controls the type of {{RelNode}} created by this
> rule).
> Suppose you have an instance of {{FilterJoinRule}} and you want to change
> {{smart}} from true to false. The {{smart}} parameter is immutable (good!)
> but you can’t easily create a clone of the rule because you don’t know the
> values of the other parameters. Your instance might even be (unbeknownst to
> you) a sub-class with extra parameters and a private constructor.
> So, my proposal is to put all of the config information of a {{RelOptRule}}
> into a single {{config}} parameter that contains all relevant properties.
> Each sub-class of {{RelOptRule}} would have one constructor with just a
> ‘config’ parameter. Each config knows which sub-class of {{RelOptRule}} to
> create. Therefore it is easy to copy a config, change one or more properties,
> and create a new rule instance.
> Adding a property to a rule’s config does not require us to add or deprecate
> any constructors.
> The operands are part of the config, so if you have a rule that matches a
> {{EnumerableFilter}} on an {{EnumerableJoin}} and you want to make it match
> an {{EnumerableFilter}} on an {{EnumerableNestedLoopJoin}}, you can easily
> create one with one changed operand.
> The config is immutable and self-describing, so we can use it to
> automatically generate a unique description for each rule instance.
> (See the email thread [[DISCUSS] Refactor how planner rules are
> parameterized|https://lists.apache.org/thread.html/rfdf6f9b7821988bdd92b0377e3d293443a6376f4773c4c658c891cf9%40%3Cdev.calcite.apache.org%3E].)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (CALCITE-3923) Refactor how planner rules are parameterized
[
https://issues.apache.org/jira/browse/CALCITE-3923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde reassigned CALCITE-3923:
Assignee: Julian Hyde
> Refactor how planner rules are parameterized
>
>
> Key: CALCITE-3923
> URL: https://issues.apache.org/jira/browse/CALCITE-3923
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
>
> People often want different variants of planner rules. An example is
> {{FilterJoinRule}}, which has a 'boolean smart’ parameter, a predicate (which
> returns whether to pull up filter conditions), operands (which determine the
> precise sub-classes of {{RelNode}} that the rule should match) and a
> {{RelBuilderFactory}} (which controls the type of {{RelNode}} created by this
> rule).
> Suppose you have an instance of {{FilterJoinRule}} and you want to change
> {{smart}} from true to false. The {{smart}} parameter is immutable (good!)
> but you can’t easily create a clone of the rule because you don’t know the
> values of the other parameters. Your instance might even be (unbeknownst to
> you) a sub-class with extra parameters and a private constructor.
> So, my proposal is to put all of the config information of a {{RelOptRule}}
> into a single {{config}} parameter that contains all relevant properties.
> Each sub-class of {{RelOptRule}} would have one constructor with just a
> ‘config’ parameter. Each config knows which sub-class of {{RelOptRule}} to
> create. Therefore it is easy to copy a config, change one or more properties,
> and create a new rule instance.
> Adding a property to a rule’s config does not require us to add or deprecate
> any constructors.
> The operands are part of the config, so if you have a rule that matches a
> {{EnumerableFilter}} on an {{EnumerableJoin}} and you want to make it match
> an {{EnumerableFilter}} on an {{EnumerableNestedLoopJoin}}, you can easily
> create one with one changed operand.
> The config is immutable and self-describing, so we can use it to
> automatically generate a unique description for each rule instance.
> (See the email thread [[DISCUSS] Refactor how planner rules are
> parameterized|https://lists.apache.org/thread.html/rfdf6f9b7821988bdd92b0377e3d293443a6376f4773c4c658c891cf9%40%3Cdev.calcite.apache.org%3E].)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3927) RelSubset is not fired for rule when set gets merged
[ https://issues.apache.org/jira/browse/CALCITE-3927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17084302#comment-17084302 ] Xiening Dai commented on CALCITE-3927: -- Can we come up with a test case? Just try to assess the impact of this in real world scenarios. > RelSubset is not fired for rule when set gets merged > > > Key: CALCITE-3927 > URL: https://issues.apache.org/jira/browse/CALCITE-3927 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: Haisheng Yuan >Priority: Major > > In VolcanoPlanner, when set gets merged, planner fires rules again for > RelNodes in both sets, but not for RelSubset. We might miss something because > of this. > If all the logical transformation rules and physical implementation rules are > separated out in different stage and physical rules don't do logical work, we > might be OK. But the reality is that all the things are mixed together at the > moment. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-3927) RelSubset is not fired for rule when set gets merged
[ https://issues.apache.org/jira/browse/CALCITE-3927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Haisheng Yuan updated CALCITE-3927: --- Description: In VolcanoPlanner, when set gets merged, planner fires rules again for RelNodes in both sets, but not for RelSubset. We might miss something because of this. If all the logical transformation rules and physical implementation rules are separated out in different stage and physical rules don't do logical work, we might be OK. But the reality is that all the things are mixed together at the moment. was: In VolcanoPlanner, when set gets merged, planner fires rules again for RelNodes in both sets, but not for RelSubset. We might miss something because of this. If all the logical transformation rules and physical implementation rules are separated out and physical rules don't do logical work, we might be OK. But the reality is that all the things are mixed together at the moment. > RelSubset is not fired for rule when set gets merged > > > Key: CALCITE-3927 > URL: https://issues.apache.org/jira/browse/CALCITE-3927 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: Haisheng Yuan >Priority: Major > > In VolcanoPlanner, when set gets merged, planner fires rules again for > RelNodes in both sets, but not for RelSubset. We might miss something because > of this. > If all the logical transformation rules and physical implementation rules are > separated out in different stage and physical rules don't do logical work, we > might be OK. But the reality is that all the things are mixed together at the > moment. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-3927) RelSubset is not fired for rule when set gets merged
Haisheng Yuan created CALCITE-3927: -- Summary: RelSubset is not fired for rule when set gets merged Key: CALCITE-3927 URL: https://issues.apache.org/jira/browse/CALCITE-3927 Project: Calcite Issue Type: Bug Components: core Reporter: Haisheng Yuan In VolcanoPlanner, when set gets merged, planner fires rules again for RelNodes in both sets, but not for RelSubset. We might miss something because of this. If all the logical transformation rules and physical implementation rules are separated out and physical rules don't do logical work, we might be OK. But the reality is that all the things are mixed together at the moment. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3926) CannotPlanException when an empty LogicalValues requires a certain collation
[
https://issues.apache.org/jira/browse/CALCITE-3926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17084260#comment-17084260
]
Ruben Q L commented on CALCITE-3926:
[~hyuan], I have submitted a PR, please take a look if you have some time.
> CannotPlanException when an empty LogicalValues requires a certain collation
>
>
> Key: CALCITE-3926
> URL: https://issues.apache.org/jira/browse/CALCITE-3926
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.23.0
>Reporter: Ruben Q L
>Priority: Blocker
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The issue can be reproduced with the following test (in RelBuilderTest.java):
> {code:java}
> @Test void testEmptyValues() throws Exception {
> final RelBuilder builder = RelBuilder.create(config().build());
> final RelNode root =
> builder
> .scan("DEPT")
> .filter(builder.literal(false)) // generates an empty
> LogicalValues
> .sort(
> builder.field("DNAME"),
> builder.field("DEPTNO"))
> .build();
> try (PreparedStatement preparedStatement = RelRunners.run(root)) {
> final String s =
> CalciteAssert.toString(preparedStatement.executeQuery());
> final String result = "";
> assertThat(s, is(result));
> }
> }
> {code}
> The test fails with the following message:
> {code:java}
> Caused by: org.apache.calcite.plan.RelOptPlanner$CannotPlanException: There
> are not enough rules to produce a node with desired properties:
> convention=ENUMERABLE, sort=[1, 0].
> Missing conversion is LogicalValues[convention: NONE -> ENUMERABLE, sort:
> [[0, 1, 2], [1, 2], [2]] -> [1, 0]]
> There is 1 empty subset: rel#14:Subset#0.ENUMERABLE.[1, 0], the relevant part
> of the original plan is as follows
> 1:LogicalValues(tuples=[[]])
> {code}
> The issue seems to be caused by the empty values: Scan + Filter(false) =>
> LogicalValues(tuples=[[]]).
> This empty LogicalValues has as collation (in case of 3 fields): [[0, 1, 2],
> [1, 2], [2]]; and in the plan we are requesting as sort collation [1, 0].
> This could be achieved by: EnumerableSort(sort=[1,0]) +
> EnumerableValues(tuples=[[]]) ; but for some reason this plan is not
> generated.
> It seems the issue was somehow introduced by CALCITE-3886
>
> [https://github.com/apache/calcite/commit/08f4a9889728f94903ff424ed9c20d940b821af5]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3926) CannotPlanException when an empty LogicalValues requires a certain collation
[
https://issues.apache.org/jira/browse/CALCITE-3926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-3926:
Labels: pull-request-available (was: )
> CannotPlanException when an empty LogicalValues requires a certain collation
>
>
> Key: CALCITE-3926
> URL: https://issues.apache.org/jira/browse/CALCITE-3926
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.23.0
>Reporter: Ruben Q L
>Priority: Blocker
> Labels: pull-request-available
>
> The issue can be reproduced with the following test (in RelBuilderTest.java):
> {code:java}
> @Test void testEmptyValues() throws Exception {
> final RelBuilder builder = RelBuilder.create(config().build());
> final RelNode root =
> builder
> .scan("DEPT")
> .filter(builder.literal(false)) // generates an empty
> LogicalValues
> .sort(
> builder.field("DNAME"),
> builder.field("DEPTNO"))
> .build();
> try (PreparedStatement preparedStatement = RelRunners.run(root)) {
> final String s =
> CalciteAssert.toString(preparedStatement.executeQuery());
> final String result = "";
> assertThat(s, is(result));
> }
> }
> {code}
> The test fails with the following message:
> {code:java}
> Caused by: org.apache.calcite.plan.RelOptPlanner$CannotPlanException: There
> are not enough rules to produce a node with desired properties:
> convention=ENUMERABLE, sort=[1, 0].
> Missing conversion is LogicalValues[convention: NONE -> ENUMERABLE, sort:
> [[0, 1, 2], [1, 2], [2]] -> [1, 0]]
> There is 1 empty subset: rel#14:Subset#0.ENUMERABLE.[1, 0], the relevant part
> of the original plan is as follows
> 1:LogicalValues(tuples=[[]])
> {code}
> The issue seems to be caused by the empty values: Scan + Filter(false) =>
> LogicalValues(tuples=[[]]).
> This empty LogicalValues has as collation (in case of 3 fields): [[0, 1, 2],
> [1, 2], [2]]; and in the plan we are requesting as sort collation [1, 0].
> This could be achieved by: EnumerableSort(sort=[1,0]) +
> EnumerableValues(tuples=[[]]) ; but for some reason this plan is not
> generated.
> It seems the issue was somehow introduced by CALCITE-3886
>
> [https://github.com/apache/calcite/commit/08f4a9889728f94903ff424ed9c20d940b821af5]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3926) CannotPlanException when an empty LogicalValues requires a certain collation
[
https://issues.apache.org/jira/browse/CALCITE-3926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17084254#comment-17084254
]
Haisheng Yuan commented on CALCITE-3926:
Hi [~rubenql], same conclusion here. Please go ahead and open the pull request.
Thanks!
The culprit is that logical operators are allowed to have traits, which is
really a disappointing design decision.
> CannotPlanException when an empty LogicalValues requires a certain collation
>
>
> Key: CALCITE-3926
> URL: https://issues.apache.org/jira/browse/CALCITE-3926
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.23.0
>Reporter: Ruben Q L
>Priority: Blocker
>
> The issue can be reproduced with the following test (in RelBuilderTest.java):
> {code:java}
> @Test void testEmptyValues() throws Exception {
> final RelBuilder builder = RelBuilder.create(config().build());
> final RelNode root =
> builder
> .scan("DEPT")
> .filter(builder.literal(false)) // generates an empty
> LogicalValues
> .sort(
> builder.field("DNAME"),
> builder.field("DEPTNO"))
> .build();
> try (PreparedStatement preparedStatement = RelRunners.run(root)) {
> final String s =
> CalciteAssert.toString(preparedStatement.executeQuery());
> final String result = "";
> assertThat(s, is(result));
> }
> }
> {code}
> The test fails with the following message:
> {code:java}
> Caused by: org.apache.calcite.plan.RelOptPlanner$CannotPlanException: There
> are not enough rules to produce a node with desired properties:
> convention=ENUMERABLE, sort=[1, 0].
> Missing conversion is LogicalValues[convention: NONE -> ENUMERABLE, sort:
> [[0, 1, 2], [1, 2], [2]] -> [1, 0]]
> There is 1 empty subset: rel#14:Subset#0.ENUMERABLE.[1, 0], the relevant part
> of the original plan is as follows
> 1:LogicalValues(tuples=[[]])
> {code}
> The issue seems to be caused by the empty values: Scan + Filter(false) =>
> LogicalValues(tuples=[[]]).
> This empty LogicalValues has as collation (in case of 3 fields): [[0, 1, 2],
> [1, 2], [2]]; and in the plan we are requesting as sort collation [1, 0].
> This could be achieved by: EnumerableSort(sort=[1,0]) +
> EnumerableValues(tuples=[[]]) ; but for some reason this plan is not
> generated.
> It seems the issue was somehow introduced by CALCITE-3886
>
> [https://github.com/apache/calcite/commit/08f4a9889728f94903ff424ed9c20d940b821af5]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3926) CannotPlanException when an empty LogicalValues requires a certain collation
[
https://issues.apache.org/jira/browse/CALCITE-3926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17084247#comment-17084247
]
Ruben Q L commented on CALCITE-3926:
Thanks [~hyuan]. I might be able to provide a patch based on the following
approach:
- PruneEmptyRules: when converting {{Sort + (Empty)Values => (Empty)Values}}
the resulting Values should have the sort's collation (we can assume that the
EmptyValues has been "sorted" following the Sort's collation). This collation
info would need to be propagated (e.g. from LogicalValues to EnumerableValues
in EnumerableValuesRule)
> CannotPlanException when an empty LogicalValues requires a certain collation
>
>
> Key: CALCITE-3926
> URL: https://issues.apache.org/jira/browse/CALCITE-3926
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.23.0
>Reporter: Ruben Q L
>Priority: Blocker
>
> The issue can be reproduced with the following test (in RelBuilderTest.java):
> {code:java}
> @Test void testEmptyValues() throws Exception {
> final RelBuilder builder = RelBuilder.create(config().build());
> final RelNode root =
> builder
> .scan("DEPT")
> .filter(builder.literal(false)) // generates an empty
> LogicalValues
> .sort(
> builder.field("DNAME"),
> builder.field("DEPTNO"))
> .build();
> try (PreparedStatement preparedStatement = RelRunners.run(root)) {
> final String s =
> CalciteAssert.toString(preparedStatement.executeQuery());
> final String result = "";
> assertThat(s, is(result));
> }
> }
> {code}
> The test fails with the following message:
> {code:java}
> Caused by: org.apache.calcite.plan.RelOptPlanner$CannotPlanException: There
> are not enough rules to produce a node with desired properties:
> convention=ENUMERABLE, sort=[1, 0].
> Missing conversion is LogicalValues[convention: NONE -> ENUMERABLE, sort:
> [[0, 1, 2], [1, 2], [2]] -> [1, 0]]
> There is 1 empty subset: rel#14:Subset#0.ENUMERABLE.[1, 0], the relevant part
> of the original plan is as follows
> 1:LogicalValues(tuples=[[]])
> {code}
> The issue seems to be caused by the empty values: Scan + Filter(false) =>
> LogicalValues(tuples=[[]]).
> This empty LogicalValues has as collation (in case of 3 fields): [[0, 1, 2],
> [1, 2], [2]]; and in the plan we are requesting as sort collation [1, 0].
> This could be achieved by: EnumerableSort(sort=[1,0]) +
> EnumerableValues(tuples=[[]]) ; but for some reason this plan is not
> generated.
> It seems the issue was somehow introduced by CALCITE-3886
>
> [https://github.com/apache/calcite/commit/08f4a9889728f94903ff424ed9c20d940b821af5]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3926) CannotPlanException when an empty LogicalValues requires a certain collation
[
https://issues.apache.org/jira/browse/CALCITE-3926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Haisheng Yuan updated CALCITE-3926:
---
Attachment: (was: image-2020-04-15-11-14-41-581.png)
> CannotPlanException when an empty LogicalValues requires a certain collation
>
>
> Key: CALCITE-3926
> URL: https://issues.apache.org/jira/browse/CALCITE-3926
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.23.0
>Reporter: Ruben Q L
>Priority: Blocker
>
> The issue can be reproduced with the following test (in RelBuilderTest.java):
> {code:java}
> @Test void testEmptyValues() throws Exception {
> final RelBuilder builder = RelBuilder.create(config().build());
> final RelNode root =
> builder
> .scan("DEPT")
> .filter(builder.literal(false)) // generates an empty
> LogicalValues
> .sort(
> builder.field("DNAME"),
> builder.field("DEPTNO"))
> .build();
> try (PreparedStatement preparedStatement = RelRunners.run(root)) {
> final String s =
> CalciteAssert.toString(preparedStatement.executeQuery());
> final String result = "";
> assertThat(s, is(result));
> }
> }
> {code}
> The test fails with the following message:
> {code:java}
> Caused by: org.apache.calcite.plan.RelOptPlanner$CannotPlanException: There
> are not enough rules to produce a node with desired properties:
> convention=ENUMERABLE, sort=[1, 0].
> Missing conversion is LogicalValues[convention: NONE -> ENUMERABLE, sort:
> [[0, 1, 2], [1, 2], [2]] -> [1, 0]]
> There is 1 empty subset: rel#14:Subset#0.ENUMERABLE.[1, 0], the relevant part
> of the original plan is as follows
> 1:LogicalValues(tuples=[[]])
> {code}
> The issue seems to be caused by the empty values: Scan + Filter(false) =>
> LogicalValues(tuples=[[]]).
> This empty LogicalValues has as collation (in case of 3 fields): [[0, 1, 2],
> [1, 2], [2]]; and in the plan we are requesting as sort collation [1, 0].
> This could be achieved by: EnumerableSort(sort=[1,0]) +
> EnumerableValues(tuples=[[]]) ; but for some reason this plan is not
> generated.
> It seems the issue was somehow introduced by CALCITE-3886
>
> [https://github.com/apache/calcite/commit/08f4a9889728f94903ff424ed9c20d940b821af5]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3926) CannotPlanException when an empty LogicalValues requires a certain collation
[
https://issues.apache.org/jira/browse/CALCITE-3926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Haisheng Yuan updated CALCITE-3926:
---
Attachment: image-2020-04-15-11-14-41-581.png
> CannotPlanException when an empty LogicalValues requires a certain collation
>
>
> Key: CALCITE-3926
> URL: https://issues.apache.org/jira/browse/CALCITE-3926
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.23.0
>Reporter: Ruben Q L
>Priority: Blocker
> Attachments: image-2020-04-15-11-14-41-581.png
>
>
> The issue can be reproduced with the following test (in RelBuilderTest.java):
> {code:java}
> @Test void testEmptyValues() throws Exception {
> final RelBuilder builder = RelBuilder.create(config().build());
> final RelNode root =
> builder
> .scan("DEPT")
> .filter(builder.literal(false)) // generates an empty
> LogicalValues
> .sort(
> builder.field("DNAME"),
> builder.field("DEPTNO"))
> .build();
> try (PreparedStatement preparedStatement = RelRunners.run(root)) {
> final String s =
> CalciteAssert.toString(preparedStatement.executeQuery());
> final String result = "";
> assertThat(s, is(result));
> }
> }
> {code}
> The test fails with the following message:
> {code:java}
> Caused by: org.apache.calcite.plan.RelOptPlanner$CannotPlanException: There
> are not enough rules to produce a node with desired properties:
> convention=ENUMERABLE, sort=[1, 0].
> Missing conversion is LogicalValues[convention: NONE -> ENUMERABLE, sort:
> [[0, 1, 2], [1, 2], [2]] -> [1, 0]]
> There is 1 empty subset: rel#14:Subset#0.ENUMERABLE.[1, 0], the relevant part
> of the original plan is as follows
> 1:LogicalValues(tuples=[[]])
> {code}
> The issue seems to be caused by the empty values: Scan + Filter(false) =>
> LogicalValues(tuples=[[]]).
> This empty LogicalValues has as collation (in case of 3 fields): [[0, 1, 2],
> [1, 2], [2]]; and in the plan we are requesting as sort collation [1, 0].
> This could be achieved by: EnumerableSort(sort=[1,0]) +
> EnumerableValues(tuples=[[]]) ; but for some reason this plan is not
> generated.
> It seems the issue was somehow introduced by CALCITE-3886
>
> [https://github.com/apache/calcite/commit/08f4a9889728f94903ff424ed9c20d940b821af5]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3926) CannotPlanException when an empty LogicalValues requires a certain collation
[
https://issues.apache.org/jira/browse/CALCITE-3926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17084110#comment-17084110
]
Haisheng Yuan commented on CALCITE-3926:
Thanks for reporting, I will take a look.
> CannotPlanException when an empty LogicalValues requires a certain collation
>
>
> Key: CALCITE-3926
> URL: https://issues.apache.org/jira/browse/CALCITE-3926
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.23.0
>Reporter: Ruben Q L
>Priority: Blocker
>
> The issue can be reproduced with the following test (in RelBuilderTest.java):
> {code:java}
> @Test void testEmptyValues() throws Exception {
> final RelBuilder builder = RelBuilder.create(config().build());
> final RelNode root =
> builder
> .scan("DEPT")
> .filter(builder.literal(false)) // generates an empty
> LogicalValues
> .sort(
> builder.field("DNAME"),
> builder.field("DEPTNO"))
> .build();
> try (PreparedStatement preparedStatement = RelRunners.run(root)) {
> final String s =
> CalciteAssert.toString(preparedStatement.executeQuery());
> final String result = "";
> assertThat(s, is(result));
> }
> }
> {code}
> The test fails with the following message:
> {code:java}
> Caused by: org.apache.calcite.plan.RelOptPlanner$CannotPlanException: There
> are not enough rules to produce a node with desired properties:
> convention=ENUMERABLE, sort=[1, 0].
> Missing conversion is LogicalValues[convention: NONE -> ENUMERABLE, sort:
> [[0, 1, 2], [1, 2], [2]] -> [1, 0]]
> There is 1 empty subset: rel#14:Subset#0.ENUMERABLE.[1, 0], the relevant part
> of the original plan is as follows
> 1:LogicalValues(tuples=[[]])
> {code}
> The issue seems to be caused by the empty values: Scan + Filter(false) =>
> LogicalValues(tuples=[[]]).
> This empty LogicalValues has as collation (in case of 3 fields): [[0, 1, 2],
> [1, 2], [2]]; and in the plan we are requesting as sort collation [1, 0].
> This could be achieved by: EnumerableSort(sort=[1,0]) +
> EnumerableValues(tuples=[[]]) ; but for some reason this plan is not
> generated.
> It seems the issue was somehow introduced by CALCITE-3886
>
> [https://github.com/apache/calcite/commit/08f4a9889728f94903ff424ed9c20d940b821af5]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3926) CannotPlanException when an empty LogicalValues requires a certain collation
[
https://issues.apache.org/jira/browse/CALCITE-3926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ruben Q L updated CALCITE-3926:
---
Description:
The issue can be reproduced with the following test (in RelBuilderTest.java):
{code:java}
@Test void testEmptyValues() throws Exception {
final RelBuilder builder = RelBuilder.create(config().build());
final RelNode root =
builder
.scan("DEPT")
.filter(builder.literal(false)) // generates an empty LogicalValues
.sort(
builder.field("DNAME"),
builder.field("DEPTNO"))
.build();
try (PreparedStatement preparedStatement = RelRunners.run(root)) {
final String s = CalciteAssert.toString(preparedStatement.executeQuery());
final String result = "";
assertThat(s, is(result));
}
}
{code}
The test fails with the following message:
{code:java}
Caused by: org.apache.calcite.plan.RelOptPlanner$CannotPlanException: There are
not enough rules to produce a node with desired properties:
convention=ENUMERABLE, sort=[1, 0].
Missing conversion is LogicalValues[convention: NONE -> ENUMERABLE, sort: [[0,
1, 2], [1, 2], [2]] -> [1, 0]]
There is 1 empty subset: rel#14:Subset#0.ENUMERABLE.[1, 0], the relevant part
of the original plan is as follows
1:LogicalValues(tuples=[[]])
{code}
The issue seems to be caused by the empty values: Scan + Filter(false) =>
LogicalValues(tuples=[[]]).
This empty LogicalValues has as collation (in case of 3 fields): [[0, 1, 2],
[1, 2], [2]]; and in the plan we are requesting as sort collation [1, 0].
This could be achieved by: EnumerableSort(sort=[1,0]) +
EnumerableValues(tuples=[[]]) ; but for some reason this plan is not generated.
It seems the issue was somehow introduced by CALCITE-3886
[https://github.com/apache/calcite/commit/08f4a9889728f94903ff424ed9c20d940b821af5]
was:
The issue can be reproduced with the following test (in RelBuilderTest.java):
{code:java}
@Test void testEmptyValues() throws Exception {
final RelBuilder builder = RelBuilder.create(config().build());
final RelNode root =
builder
.scan("DEPT")
.filter(builder.literal(false)) // generates an empty LogicalValues
.sort(
builder.field("DNAME"),
builder.field("DEPTNO"))
.build();
try (PreparedStatement preparedStatement = RelRunners.run(root)) {
final String s = CalciteAssert.toString(preparedStatement.executeQuery());
final String result = "";
assertThat(s, is(result));
}
}
{code}
The test fails with the following message:
{code:java}
Caused by: org.apache.calcite.plan.RelOptPlanner$CannotPlanException: There are
not enough rules to produce a node with desired properties:
convention=ENUMERABLE, sort=[1, 0].
Missing conversion is LogicalValues[convention: NONE -> ENUMERABLE, sort: [[0,
1, 2], [1, 2], [2]] -> [1, 0]]
There is 1 empty subset: rel#14:Subset#0.ENUMERABLE.[1, 0], the relevant part
of the original plan is as follows
1:LogicalValues(tuples=[[]])
{code}
The issue seems to be caused by the empty values: Scan + Filter(false) =>
LogicalValues({}).
This empty LogicalValues has as collation (in case of 3 fields): [[0, 1, 2],
[1, 2], [2]]; and in the plan we are requesting as sort collation [1, 0].
It seems the issue was somehow introduced by CALCITE-3886
[https://github.com/apache/calcite/commit/08f4a9889728f94903ff424ed9c20d940b821af5]
> CannotPlanException when an empty LogicalValues requires a certain collation
>
>
> Key: CALCITE-3926
> URL: https://issues.apache.org/jira/browse/CALCITE-3926
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.23.0
>Reporter: Ruben Q L
>Priority: Blocker
>
> The issue can be reproduced with the following test (in RelBuilderTest.java):
> {code:java}
> @Test void testEmptyValues() throws Exception {
> final RelBuilder builder = RelBuilder.create(config().build());
> final RelNode root =
> builder
> .scan("DEPT")
> .filter(builder.literal(false)) // generates an empty
> LogicalValues
> .sort(
> builder.field("DNAME"),
> builder.field("DEPTNO"))
> .build();
> try (PreparedStatement preparedStatement = RelRunners.run(root)) {
> final String s =
> CalciteAssert.toString(preparedStatement.executeQuery());
> final String result = "";
> assertThat(s, is(result));
> }
> }
> {code}
> The test fails with the following message:
> {code:java}
> Caused by: org.apache.calcite.plan.RelOptPlanner$CannotPlanException: There
> are not enough rules to produce a node with desired properties:
> convention=ENUMERABLE,
[jira] [Comment Edited] (CALCITE-3926) CannotPlanException when an empty LogicalValues requires a certain collation
[
https://issues.apache.org/jira/browse/CALCITE-3926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17084078#comment-17084078
]
Ruben Q L edited comment on CALCITE-3926 at 4/15/20, 1:25 PM:
--
Note that: if we remove {{PruneEmptyRules.SORT_INSTANCE}} from the planner, the
plan execution succeeds:
{code:java}
@Test void testEmptyValues() {
tester(false, new JdbcTest.HrSchema())
.query("?")
// removing PruneEmptyRules.SORT_INSTANCE: test ok; otherwise test fails
.withHook(Hook.PLANNER, (Consumer) planner ->
planner.removeRule(PruneEmptyRules.SORT_INSTANCE))
.withRel(
builder -> builder
.scan("s", "depts").as("d")
.filter(
builder.literal(false))
.sort(
builder.field("name"),
builder.field("deptno"))
.build())
.returnsUnordered("");
}
{code}
was (Author: rubenql):
{{Note that: if we remove PruneEmptyRules.SORT_INSTANCE from the planner, the
plan execution succeeds:}}
{code:java}
@Test void testEmptyValues() {
tester(false, new JdbcTest.HrSchema())
.query("?")
// removing PruneEmptyRules.SORT_INSTANCE: test ok; otherwise test fails
.withHook(Hook.PLANNER, (Consumer) planner ->
planner.removeRule(PruneEmptyRules.SORT_INSTANCE))
.withRel(
builder -> builder
.scan("s", "depts").as("d")
.filter(
builder.literal(false))
.sort(
builder.field("name"),
builder.field("deptno"))
.build())
.returnsUnordered("");
}
{code}
> CannotPlanException when an empty LogicalValues requires a certain collation
>
>
> Key: CALCITE-3926
> URL: https://issues.apache.org/jira/browse/CALCITE-3926
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.23.0
>Reporter: Ruben Q L
>Priority: Blocker
>
> The issue can be reproduced with the following test (in RelBuilderTest.java):
> {code:java}
> @Test void testEmptyValues() throws Exception {
> final RelBuilder builder = RelBuilder.create(config().build());
> final RelNode root =
> builder
> .scan("DEPT")
> .filter(builder.literal(false)) // generates an empty
> LogicalValues
> .sort(
> builder.field("DNAME"),
> builder.field("DEPTNO"))
> .build();
> try (PreparedStatement preparedStatement = RelRunners.run(root)) {
> final String s =
> CalciteAssert.toString(preparedStatement.executeQuery());
> final String result = "";
> assertThat(s, is(result));
> }
> }
> {code}
> The test fails with the following message:
> {code:java}
> Caused by: org.apache.calcite.plan.RelOptPlanner$CannotPlanException: There
> are not enough rules to produce a node with desired properties:
> convention=ENUMERABLE, sort=[1, 0].
> Missing conversion is LogicalValues[convention: NONE -> ENUMERABLE, sort:
> [[0, 1, 2], [1, 2], [2]] -> [1, 0]]
> There is 1 empty subset: rel#14:Subset#0.ENUMERABLE.[1, 0], the relevant part
> of the original plan is as follows
> 1:LogicalValues(tuples=[[]])
> {code}
> The issue seems to be caused by the empty values: Scan + Filter(false) =>
> LogicalValues({}).
> This empty LogicalValues has as collation (in case of 3 fields): [[0, 1, 2],
> [1, 2], [2]]; and in the plan we are requesting as sort collation [1, 0].
> It seems the issue was somehow introduced by CALCITE-3886
>
> [https://github.com/apache/calcite/commit/08f4a9889728f94903ff424ed9c20d940b821af5]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-3926) CannotPlanException when an empty LogicalValues requires a certain collation
[
https://issues.apache.org/jira/browse/CALCITE-3926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17084078#comment-17084078
]
Ruben Q L edited comment on CALCITE-3926 at 4/15/20, 1:24 PM:
--
{{Note that: if we remove PruneEmptyRules.SORT_INSTANCE from the planner, the
plan execution succeeds:}}
{code:java}
@Test void testEmptyValues() {
tester(false, new JdbcTest.HrSchema())
.query("?")
// removing PruneEmptyRules.SORT_INSTANCE: test ok; otherwise test fails
.withHook(Hook.PLANNER, (Consumer) planner ->
planner.removeRule(PruneEmptyRules.SORT_INSTANCE))
.withRel(
builder -> builder
.scan("s", "depts").as("d")
.filter(
builder.literal(false))
.sort(
builder.field("name"),
builder.field("deptno"))
.build())
.returnsUnordered("");
}
{code}
was (Author: rubenql):
Note that: if we remove PruneEmptyRules.SORT_INSTANCE from the planner, the
plan execution succeeds:
{code}
@Test void testEmptyValues() {
tester(false, new JdbcTest.HrSchema())
.query("?")
// removing PruneEmptyRules.SORT_INSTANCE: test ok; otherwise test fails
.withHook(Hook.PLANNER, (Consumer) planner ->
planner.removeRule(PruneEmptyRules.SORT_INSTANCE))
.withRel(
builder -> builder
.scan("s", "depts").as("d")
.filter(
builder.literal(false))
.sort(
builder.field("name"),
builder.field("deptno"))
.build())
.returnsUnordered("");
}
{code}
> CannotPlanException when an empty LogicalValues requires a certain collation
>
>
> Key: CALCITE-3926
> URL: https://issues.apache.org/jira/browse/CALCITE-3926
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.23.0
>Reporter: Ruben Q L
>Priority: Blocker
>
> The issue can be reproduced with the following test (in RelBuilderTest.java):
> {code:java}
> @Test void testEmptyValues() throws Exception {
> final RelBuilder builder = RelBuilder.create(config().build());
> final RelNode root =
> builder
> .scan("DEPT")
> .filter(builder.literal(false)) // generates an empty
> LogicalValues
> .sort(
> builder.field("DNAME"),
> builder.field("DEPTNO"))
> .build();
> try (PreparedStatement preparedStatement = RelRunners.run(root)) {
> final String s =
> CalciteAssert.toString(preparedStatement.executeQuery());
> final String result = "";
> assertThat(s, is(result));
> }
> }
> {code}
> The test fails with the following message:
> {code:java}
> Caused by: org.apache.calcite.plan.RelOptPlanner$CannotPlanException: There
> are not enough rules to produce a node with desired properties:
> convention=ENUMERABLE, sort=[1, 0].
> Missing conversion is LogicalValues[convention: NONE -> ENUMERABLE, sort:
> [[0, 1, 2], [1, 2], [2]] -> [1, 0]]
> There is 1 empty subset: rel#14:Subset#0.ENUMERABLE.[1, 0], the relevant part
> of the original plan is as follows
> 1:LogicalValues(tuples=[[]])
> {code}
> The issue seems to be caused by the empty values: Scan + Filter(false) =>
> LogicalValues({}).
> This empty LogicalValues has as collation (in case of 3 fields): [[0, 1, 2],
> [1, 2], [2]]; and in the plan we are requesting as sort collation [1, 0].
> It seems the issue was somehow introduced by CALCITE-3886
>
> [https://github.com/apache/calcite/commit/08f4a9889728f94903ff424ed9c20d940b821af5]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3926) CannotPlanException when an empty LogicalValues requires a certain collation
[
https://issues.apache.org/jira/browse/CALCITE-3926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17084078#comment-17084078
]
Ruben Q L commented on CALCITE-3926:
Note that: if we remove PruneEmptyRules.SORT_INSTANCE from the planner, the
plan execution succeeds:
{code}
@Test void testEmptyValues() {
tester(false, new JdbcTest.HrSchema())
.query("?")
// removing PruneEmptyRules.SORT_INSTANCE: test ok; otherwise test fails
.withHook(Hook.PLANNER, (Consumer) planner ->
planner.removeRule(PruneEmptyRules.SORT_INSTANCE))
.withRel(
builder -> builder
.scan("s", "depts").as("d")
.filter(
builder.literal(false))
.sort(
builder.field("name"),
builder.field("deptno"))
.build())
.returnsUnordered("");
}
{code}
> CannotPlanException when an empty LogicalValues requires a certain collation
>
>
> Key: CALCITE-3926
> URL: https://issues.apache.org/jira/browse/CALCITE-3926
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.23.0
>Reporter: Ruben Q L
>Priority: Blocker
>
> The issue can be reproduced with the following test (in RelBuilderTest.java):
> {code:java}
> @Test void testEmptyValues() throws Exception {
> final RelBuilder builder = RelBuilder.create(config().build());
> final RelNode root =
> builder
> .scan("DEPT")
> .filter(builder.literal(false)) // generates an empty
> LogicalValues
> .sort(
> builder.field("DNAME"),
> builder.field("DEPTNO"))
> .build();
> try (PreparedStatement preparedStatement = RelRunners.run(root)) {
> final String s =
> CalciteAssert.toString(preparedStatement.executeQuery());
> final String result = "";
> assertThat(s, is(result));
> }
> }
> {code}
> The test fails with the following message:
> {code:java}
> Caused by: org.apache.calcite.plan.RelOptPlanner$CannotPlanException: There
> are not enough rules to produce a node with desired properties:
> convention=ENUMERABLE, sort=[1, 0].
> Missing conversion is LogicalValues[convention: NONE -> ENUMERABLE, sort:
> [[0, 1, 2], [1, 2], [2]] -> [1, 0]]
> There is 1 empty subset: rel#14:Subset#0.ENUMERABLE.[1, 0], the relevant part
> of the original plan is as follows
> 1:LogicalValues(tuples=[[]])
> {code}
> The issue seems to be caused by the empty values: Scan + Filter(false) =>
> LogicalValues({}).
> This empty LogicalValues has as collation (in case of 3 fields): [[0, 1, 2],
> [1, 2], [2]]; and in the plan we are requesting as sort collation [1, 0].
> It seems the issue was somehow introduced by CALCITE-3886
>
> [https://github.com/apache/calcite/commit/08f4a9889728f94903ff424ed9c20d940b821af5]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3925) Support materialized view matching for LogicalCorrelate in SubsitutionVisitor
[ https://issues.apache.org/jira/browse/CALCITE-3925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17084064#comment-17084064 ] Jin Xing commented on CALCITE-3925: --- Sure ~ You can refer to matching implementation for Join when working on this one. > Support materialized view matching for LogicalCorrelate in SubsitutionVisitor > - > > Key: CALCITE-3925 > URL: https://issues.apache.org/jira/browse/CALCITE-3925 > Project: Calcite > Issue Type: Bug >Reporter: Jin Xing >Priority: Major > > LogicalCorrelate is widely used in user SQLs to performs nested-loop join. > We need to support substitution based materialized view matching for it. The > matching algorithm should be able to do Project & Filter compensation when > matching query with materialized view. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3925) Support materialized view matching for LogicalCorrelate in SubsitutionVisitor
[ https://issues.apache.org/jira/browse/CALCITE-3925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17084063#comment-17084063 ] xzh_dz commented on CALCITE-3925: - Hi Jin~ I have much interest on this JIRA and want to work on it ~ Can you assign this one to me ? > Support materialized view matching for LogicalCorrelate in SubsitutionVisitor > - > > Key: CALCITE-3925 > URL: https://issues.apache.org/jira/browse/CALCITE-3925 > Project: Calcite > Issue Type: Bug >Reporter: Jin Xing >Priority: Major > > LogicalCorrelate is widely used in user SQLs to performs nested-loop join. > We need to support substitution based materialized view matching for it. The > matching algorithm should be able to do Project & Filter compensation when > matching query with materialized view. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-3758) FilterTableScanRule generate wrong mapping for filter condition when underlying is BindableTableScan
[ https://issues.apache.org/jira/browse/CALCITE-3758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jin Xing updated CALCITE-3758: -- Description: When FilterTableScanRule push filter condition into ProjectableFilterableTable, the filter condition should be adjusted to be based on the internal table of BindableTableScan. (was: When FilterTableScanRule push filter condition into ProjectableFilterableTable, the filter condition should be adjusted to be based on the internal table of BindableTableScan. This line[1] is rectified as *Mappings.source* [1][https://github.com/apache/calcite/blob/571731b80a58eb095ebac7123285c375e7afff90/core/src/main/java/org/apache/calcite/rel/rules/FilterTableScanRule.java#L124]) > FilterTableScanRule generate wrong mapping for filter condition when > underlying is BindableTableScan > > > Key: CALCITE-3758 > URL: https://issues.apache.org/jira/browse/CALCITE-3758 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jin Xing >Assignee: Jin Xing >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > When FilterTableScanRule push filter condition into > ProjectableFilterableTable, the filter condition should be adjusted to be > based on the internal table of BindableTableScan. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-3926) CannotPlanException when an empty LogicalValues requires a certain collation
Ruben Q L created CALCITE-3926:
--
Summary: CannotPlanException when an empty LogicalValues requires
a certain collation
Key: CALCITE-3926
URL: https://issues.apache.org/jira/browse/CALCITE-3926
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.23.0
Reporter: Ruben Q L
The issue can be reproduced with the following test (in RelBuilderTest.java):
{code:java}
@Test void testEmptyValues() throws Exception {
final RelBuilder builder = RelBuilder.create(config().build());
final RelNode root =
builder
.scan("DEPT")
.filter(builder.literal(false)) // generates an empty LogicalValues
.sort(
builder.field("DNAME"),
builder.field("DEPTNO"))
.build();
try (PreparedStatement preparedStatement = RelRunners.run(root)) {
final String s = CalciteAssert.toString(preparedStatement.executeQuery());
final String result = "";
assertThat(s, is(result));
}
}
{code}
The test fails with the following message:
{code:java}
Caused by: org.apache.calcite.plan.RelOptPlanner$CannotPlanException: There are
not enough rules to produce a node with desired properties:
convention=ENUMERABLE, sort=[1, 0].
Missing conversion is LogicalValues[convention: NONE -> ENUMERABLE, sort: [[0,
1, 2], [1, 2], [2]] -> [1, 0]]
There is 1 empty subset: rel#14:Subset#0.ENUMERABLE.[1, 0], the relevant part
of the original plan is as follows
1:LogicalValues(tuples=[[]])
{code}
The issue seems to be caused by the empty values: Scan + Filter(false) =>
LogicalValues({}).
This empty LogicalValues has as collation (in case of 3 fields): [[0, 1, 2],
[1, 2], [2]]; and in the plan we are requesting as sort collation [1, 0].
It seems the issue was somehow introduced by CALCITE-3886
[https://github.com/apache/calcite/commit/08f4a9889728f94903ff424ed9c20d940b821af5]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3925) Support materialized view matching for LogicalCorrelate in SubsitutionVisitor
[ https://issues.apache.org/jira/browse/CALCITE-3925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jin Xing updated CALCITE-3925: -- Description: LogicalCorrelate is widely used in user SQLs to performs nested-loop join. We need to support substitution based materialized view matching for it. The matching algorithm should be able to do Project & Filter compensation when matching query with materialized view. (was: LogicalCorrelate is widely used in user SQLs to performs nested-loop join. We need to support substitution based materialized view matching for it. The matching algorithm should support Project & Filter compensation when matching query with materialized view.) > Support materialized view matching for LogicalCorrelate in SubsitutionVisitor > - > > Key: CALCITE-3925 > URL: https://issues.apache.org/jira/browse/CALCITE-3925 > Project: Calcite > Issue Type: Bug >Reporter: Jin Xing >Priority: Major > > LogicalCorrelate is widely used in user SQLs to performs nested-loop join. > We need to support substitution based materialized view matching for it. The > matching algorithm should be able to do Project & Filter compensation when > matching query with materialized view. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-3925) Support materialized view matching for LogicalCorrelate in SubsitutionVisitor
[ https://issues.apache.org/jira/browse/CALCITE-3925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jin Xing updated CALCITE-3925: -- Description: LogicalCorrelate is widely used in user SQLs to performs nested-loop join. We need to support substitution based materialized view matching for it. The matching algorithm should support Project & Filter compensation when matching query with materialized view. > Support materialized view matching for LogicalCorrelate in SubsitutionVisitor > - > > Key: CALCITE-3925 > URL: https://issues.apache.org/jira/browse/CALCITE-3925 > Project: Calcite > Issue Type: Bug >Reporter: Jin Xing >Priority: Major > > LogicalCorrelate is widely used in user SQLs to performs nested-loop join. > We need to support substitution based materialized view matching for it. The > matching algorithm should support Project & Filter compensation when matching > query with materialized view. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-3925) Support materialized view matching for LogicalCorrelate in SubsitutionVisitor
Jin Xing created CALCITE-3925: - Summary: Support materialized view matching for LogicalCorrelate in SubsitutionVisitor Key: CALCITE-3925 URL: https://issues.apache.org/jira/browse/CALCITE-3925 Project: Calcite Issue Type: Bug Reporter: Jin Xing -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CALCITE-3924) Fix flakey test to handle TIMESTAMP and TIMESTAMP(0) correctly
[ https://issues.apache.org/jira/browse/CALCITE-3924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danny Chen resolved CALCITE-3924. - Fix Version/s: 1.23.0 Assignee: Danny Chen Resolution: Fixed Fixed in [dfb842e|https://github.com/apache/calcite/commit/dfb842e55e1fa7037c8a731341010ed1c0cfb6f7], thanks for your PR, [~neoremind] ! > Fix flakey test to handle TIMESTAMP and TIMESTAMP(0) correctly > -- > > Key: CALCITE-3924 > URL: https://issues.apache.org/jira/browse/CALCITE-3924 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.22.0 >Reporter: neoremind >Assignee: Danny Chen >Priority: Critical > Labels: pull-request-available > Fix For: 1.23.0 > > Attachments: common_first_error.log > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Currently, building is not stable, there are frequently flakey tests on > Linux(JDK 11) related with TIMESTAMP(0) vs TIMESTAMP. > For example, > [https://github.com/apache/calcite/runs/584340845] > [https://github.com/apache/calcite/runs/576436249] > [https://github.com/apache/calcite/runs/585695121] > Below is first failure test of a consecutive failure tests from the three > builds: > _org.apache.calcite.test.SqlLimitsTest > testPrintLimits() (see attachment > log for detail)_ > _The only diff is TIMESTAMP(0) vs TIMESTAMP_ > > The root cause is: > In BasicSqlType, the value of `toString` result and instance member `digest` > might be different. For TIMESTAMP without precision (precision = -1), > toString returns TIMESTAMP and digest is TIMESTAMP(0), which conflicts with > real TIMESTAMP(0) with 0 as precision. > `Interner DATATYPE_CACHE = Interners.newWeakInterner()` makes > sure SqlType is singleton between invocations, TIMESTAMP(0) might return > SqlType - TIMESTAMP without precision literally which is wrong. Because the > global cache uses weak reference, so the cache would usually invalidate after > Java GC, which mitigates the impact of the hidden bug. As for the specific > environment Linux JDK 11 situation, I could not give a reasonable explanation > yet, but I suppose the cause is clear. > The fix is simple, making the digest of TIMESTAMP without precision > (precision = -1) as _TIMESTAMP_ instead of _TIMESTAMP(0)_ would solve the > problem. This could expand to all TIME and TIMESTAMP related sql types. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CALCITE-3881) SqlFunctions#addMonths yields incorrect results in some corner case
[
https://issues.apache.org/jira/browse/CALCITE-3881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Danny Chen resolved CALCITE-3881.
-
Fix Version/s: 1.23.0
Assignee: Danny Chen
Resolution: Fixed
Fixed in
[43261e4|https://github.com/apache/calcite/commit/43261e4094a37ce23eb181a6a8f653dabc4db599],
thanks for your PR, [~docete] !
> SqlFunctions#addMonths yields incorrect results in some corner case
> ---
>
> Key: CALCITE-3881
> URL: https://issues.apache.org/jira/browse/CALCITE-3881
> Project: Calcite
> Issue Type: Bug
> Components: avatica, core
>Affects Versions: avatica-1.16.0
>Reporter: Zhenghua Gao
>Assignee: Danny Chen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.23.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> SqlFunctions#addMonths use DateTimeUtils#ymdToUnixDate to calculate the
> JDN(julian day number). But in some corner cases it yields incorrent results.
> The root cause is: the algorithm of DateTimeUtils#ymdToUnixDate requires
> reasonable month(1 to 12)[1], but SqlFunctions#addMonths may pass in a month
> out of the reasonable range.
> BTW: I didn't find the reference of the original paper of the algorithm, but
> an jdn explanation. Please correct me if anyone can find the original paper.
>
> The following case can reproduce the bug:
> addMonth('2019-09-01', 6) should yield '2020-03-01'
> {code:java}
> @Test public void testAddMonths() {
> checkAddMonths(2019, 9, 1, 2020, 3, 1, 6);
> } {code}
>
> [1]
> [http://www.cs.utsa.edu/~cs1063/projects/Spring2011/Project1/jdn-explanation.html]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3910) Enhance ProjectJoinTransposeRule to support SemiJoin and AntiJoin
[
https://issues.apache.org/jira/browse/CALCITE-3910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-3910:
Labels: pull-request-available (was: )
> Enhance ProjectJoinTransposeRule to support SemiJoin and AntiJoin
> -
>
> Key: CALCITE-3910
> URL: https://issues.apache.org/jira/browse/CALCITE-3910
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.22.0
>Reporter: Chunwei Lei
>Assignee: Liya Fan
>Priority: Major
> Labels: pull-request-available
>
> Currently, ProjectJoinTransposeRule does not support push project pass
> SemiJoin and AntiJoin.
> {code:java}
> public void onMatch(RelOptRuleCall call) {
> Project origProj = call.rel(0);
> final Join join = call.rel(1);
> if (!join.getJoinType().projectsRight()) {
> return; // TODO: support SemiJoin / AntiJoin
> }
> ...
> ...
> }{code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
