[jira] [Commented] (CALCITE-4857) Materialization-Failed, query could be grouping mv's agg-call, when executing mv-match.
[
https://issues.apache.org/jira/browse/CALCITE-4857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17430279#comment-17430279
]
Wang Yanlin commented on CALCITE-4857:
--
How about simplify
{noformat}
select deptno, salary, max(salary), min(commission)
from emps
group by deptno, salary
{noformat}
to
{noformat}
select deptno, salary, salary as expr, min(commission)
from emps
group by deptno, salary
{noformat}
Then, the query can be matched.
> Materialization-Failed, query could be grouping mv's agg-call, when executing
> mv-match.
> ---
>
> Key: CALCITE-4857
> URL: https://issues.apache.org/jira/browse/CALCITE-4857
> Project: Calcite
> Issue Type: Bug
>Reporter: Xurenhe
>Priority: Major
> Attachments: image-2021-10-18-11-18-02-312.png
>
>
> Here, query could be rewritten by mv, but it's failed now.
> {code:java}
> -- mv:
> select deptno, salary, min(commission) as commission_min
> from emps
> group by deptno, salary
> -- query:
> select deptno, salary, max(salary), min(commission)
> from emps
> group by deptno, salary
> -- after mv match
> select deptno, salary, max(salary), commission_min
> from mv
> group by deptno, salary, commission_min
> {code}
>
> !image-2021-10-18-11-18-02-312.png!
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CALCITE-4735) SubstitutionVisitor of Aggregate Failed, when aggcalls of query could be expressed by target's grouping
[
https://issues.apache.org/jira/browse/CALCITE-4735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin resolved CALCITE-4735.
--
Resolution: Fixed
Fixed in
[https://github.com/apache/calcite/commit/46fb2632ea4457e5c0f87d42536ae2d5cdf5f07d,]
thx [~wojustme]
> SubstitutionVisitor of Aggregate Failed, when aggcalls of query could be
> expressed by target's grouping
> ---
>
> Key: CALCITE-4735
> URL: https://issues.apache.org/jira/browse/CALCITE-4735
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Xurenhe
>Assignee: Xurenhe
>Priority: Major
> Labels: pull-request-available
> Time Spent: 6h 40m
> Remaining Estimate: 0h
>
> `SubstitutionVisitor` don't work for rewriting query by mv, let me show a
> example of the current failure.
> {code:java}
> @Test void testAggCallArgExpressedByMvProjs() {
> final String mv = ""
> + "select \"deptno\", \"name\""
> + "from \"emps\" group by \"deptno\", \"name\"";
> final String query = ""
> + "select \"deptno\", \"name\", count(distinct \"name\")"
> + "from \"emps\" group by \"deptno\", \"name\"";
> sql(mv, query).ok();
> }
> {code}
> I debug this issue, I found that: when `AggregateToAggregateUnifyRule`
> executing `unifyAggregates`, code want to find agg-calls of query could be
> equal or rollup by target's agg-calls.
> Should we have other way to handle in `AggregateToAggregateUnifyRule` or
> `AggregateOnCalcToAggregateUnifyRule`?
> I will give some examples to explain the problem:
> {code:sql}
> -- schema
> create table emps (
> empid integer,
> deptno integer,
> name varchar,
> salary float,
> commission integer
> )
> {code}
>
> AggregateToAggregateUnifyRule
> case1: mv's group equal to query's group
> {code:sql}
> --mv
> select deptno, commission
> from emps
> group by deptno, commission
> --query
> select deptno, commission, count(1), count(distinct commission)
> from emps
> group by deptno, commission
> --rewrite
> select deptno, commission, count(1), count(distinct commission)
> from mv
> group by deptno, commission
> {code}
> case2: mv's group rollup to query's group
> {code:sql}
> --mv
> select deptno, commission
> from emps
> group by deptno, commission
> --query
> select deptno, max(commission)
> from emps
> group by deptno
> --rewrite
> select deptno, max(commission)
> from mv
> group by deptno
> {code}
>
> AggregateOnCalcToAggregateUnifyRule
> case1: mv's group equal to query's group
> {code:sql}
> --mv
> select deptno, commission, mix(salary)
> from emps
> group by deptno, commission
> --query
> select deptno, commission, count(1)
> from emps
> group by deptno, commission
> --rewrite
> select deptno, commission, count(1)
> from mv
> group by deptno, commission
> {code}
> case2: mv's group rollup to query's group
> {code:sql}
> --mv
> select deptno, commission, name, mix(salary)
> from emps
> group by deptno, commission, name
> --query
> select deptno, commission, count(1), count(distinct name)
> from emps
> group by deptno, commission
> --rewrite
> select deptno, commission, count(1), count(distinct name)
> from mv
> group by deptno, commission
> {code}
>
> Here, Should we create new agg-calls to compensate missing agg-calls of
> query, which is based on mv's agg-group?
> Rewriting query's agg-call could be rewritten by equal agg-call of mv or
> rollup agg-call of mv,
> also could be {color:#ff}rewritten by emitted agg-group of mv{color}.
> Please review this viewpoint, if this viewpoint is right, I can do it.
> Thanks a lot.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (CALCITE-3583) Support serialized to json and deserialized from json for Exchange relation operator
[
https://issues.apache.org/jira/browse/CALCITE-3583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin closed CALCITE-3583.
Resolution: Duplicate
Duplicate with https://issues.apache.org/jira/browse/CALCITE-4778, close this
one.
> Support serialized to json and deserialized from json for Exchange relation
> operator
>
>
> Key: CALCITE-3583
> URL: https://issues.apache.org/jira/browse/CALCITE-3583
> Project: Calcite
> Issue Type: Improvement
>Reporter: Wang Yanlin
>Priority: Major
> Labels: pull-request-available
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> Currently, serialize Exchange relnode to json will cause exception
> {code:java}
> // RelWriterTest
> @Test public void testExchange() {
> final FrameworkConfig config = RelBuilderTest.config().build();
> final RelBuilder builder = RelBuilder.create(config);
> final RelNode rel = builder
> .scan("EMP")
> .exchange(RelDistributions.hash(ImmutableList.of(0, 1)))
> .build();
> String relJson = RelOptUtil.dumpPlan("", rel,
> SqlExplainFormat.JSON, SqlExplainLevel.EXPPLAN_ATTRIBUTES);
> String s = deserializeAndDumpToTextFormat(getSchema(rel), relJson);
> final String expected = ""
> + "LogicalExchange(distribution=[hash[0, 1]])\n"
> + " LogicalTableScan(table=[[scott, EMP]])\n";
> assertThat(s, isLinux(expected));
> }
> {code}
> got
> {code:java}
> java.lang.UnsupportedOperationException: type not serializable: hash[0, 1]
> (type org.apache.calcite.rel.RelDistributions.RelDistributionImpl)
> at org.apache.calcite.rel.externalize.RelJson.toJson(RelJson.java:290)
> at
> org.apache.calcite.rel.externalize.RelJsonWriter.put(RelJsonWriter.java:83)
> at
> org.apache.calcite.rel.externalize.RelJsonWriter.explain_(RelJsonWriter.java:66)
> at
> org.apache.calcite.rel.externalize.RelJsonWriter.done(RelJsonWriter.java:128)
> at
> org.apache.calcite.rel.AbstractRelNode.explain(AbstractRelNode.java:299)
> at org.apache.calcite.plan.RelOptUtil.dumpPlan(RelOptUtil.java:1981)
> at
> org.apache.calcite.plan.RelWriterTest.testExchange(RelWriterTest.java:772)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CALCITE-4778) Exchange operator deserialize fail when the RexInput has no RelCollcation
[
https://issues.apache.org/jira/browse/CALCITE-4778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin resolved CALCITE-4778.
--
Resolution: Fixed
Fixed in
[https://github.com/apache/calcite/commit/2916b83712b517430e71c1c22042e484ee900589,]
thx [~xzh_dz]
> Exchange operator deserialize fail when the RexInput has no RelCollcation
> -
>
> Key: CALCITE-4778
> URL: https://issues.apache.org/jira/browse/CALCITE-4778
> Project: Calcite
> Issue Type: Improvement
>Reporter: xzh_dz
>Priority: Major
> Labels: pull-request-available
> Time Spent: 1h
> Remaining Estimate: 0h
>
> {code:java}
> // code placeholder
> org.apache.calcite.plan.RelWriterTest
> @Test public void testExchange() {
> final FrameworkConfig config = RelBuilderTest.config().build();
> final RelBuilder builder = RelBuilder.create(config);
> final RelNode rel = builder
> .scan("EMP")
> .exchange(RelDistributions.hash(ImmutableList.of(0, 1)))
> .build();
> final String relJson = RelOptUtil.dumpPlan("", rel,
> SqlExplainFormat.JSON, SqlExplainLevel.EXPPLAN_ATTRIBUTES);
> String s = deserializeAndDumpToTextFormat(getSchema(rel), relJson);
> final String expected = ""
> + "LogicalExchange(distribution=[hash[0, 1]])\n"
> + " LogicalTableScan(table=[[scott, EMP]])\n";
> assertThat(s, isLinux(expected));
> }
> {code}
> java.lang.NullPointerException: no entry for tag
> collationjava.lang.NullPointerException: no entry for tag
> collationjava.lang.RuntimeException: java.lang.NullPointerException: no entry
> for tag collation at
> org.apache.calcite.tools.Frameworks.withPrepare(Frameworks.java:193) at
> org.apache.calcite.tools.Frameworks.withPlanner(Frameworks.java:135) at
> org.apache.calcite.tools.Frameworks.withPlanner(Frameworks.java:153)
> Caused by: java.lang.NullPointerException: no entry for tag collationCaused
> by: java.lang.NullPointerException: no entry for tag collation at
> java.util.Objects.requireNonNull(Objects.java:290) at
> org.apache.calcite.rel.externalize.RelJsonReader$2.getNonNull(RelJsonReader.java:202)
> at
> org.apache.calcite.rel.externalize.RelJsonReader$2.getCollation(RelJsonReader.java:260)
> at org.apache.calcite.rel.core.Exchange.(Exchange.java:73) at
> org.apache.calcite.rel.logical.LogicalExchange.(LogicalExchange.java:44)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423) at
> org.apache.calcite.rel.externalize.RelJsonReader.readRel(RelJsonReader.java:289)
> at
> org.apache.calcite.rel.externalize.RelJsonReader.readRels(RelJsonReader.java:107)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CALCITE-4779) GroupByList contains constant literal, materialized view recognition failed
[
https://issues.apache.org/jira/browse/CALCITE-4779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin resolved CALCITE-4779.
--
Resolution: Fixed
Fixed in
[https://github.com/apache/calcite/commit/219e41eab20533f02d41238d1ebc617cc813b9a2,]
thx [~xzh_dz]
> GroupByList contains constant literal, materialized view recognition failed
> ---
>
> Key: CALCITE-4779
> URL: https://issues.apache.org/jira/browse/CALCITE-4779
> Project: Calcite
> Issue Type: Improvement
>Reporter: xzh_dz
>Priority: Major
> Labels: pull-request-available
> Attachments: image-2021-09-19-06-41-52-352.png
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> {code:java}
> // code placeholder
> org.apache.calcite.test.MaterializedViewSubstitutionVisitorTest
> @Test void testCountDistinct() {
> final String mv = ""
> + "select \"deptno\", \"empid\"\n"
> + "from \"emps\"\n"
> + "group by \"deptno\", \"empid\"";
> final String query = ""
> + "select 1, \"deptno\"\n"
> + "from \"emps\"\n"
> + "group by 1, \"deptno\"";
> sql(mv, query).ok();
> }
> {code}
> Materialized view failed to be matched by optimized results:Materialized view
> failed to be matched by optimized results: java.lang.AssertionError:
> Materialized view failed to be matched by optimized results: at
> org.apache.calcite.test.AbstractMaterializedViewTest.checkMaterialize(AbstractMaterializedViewTest.java:116)
> at
> org.apache.calcite.test.AbstractMaterializedViewTest.access$000(AbstractMaterializedViewTest.java:67)
> at
> org.apache.calcite.test.AbstractMaterializedViewTest$Sql.ok(AbstractMaterializedViewTest.java:229)
> at java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:627)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CALCITE-3935) Materialization-Failed, meeting to pull up bottom filter of Left/Right Join
[
https://issues.apache.org/jira/browse/CALCITE-3935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin resolved CALCITE-3935.
--
Resolution: Fixed
Fixed in
[https://github.com/apache/calcite/commit/a36f5a21f006ee717e7949269a99fa48a65f6abe.]
thx [~wojustme]
> Materialization-Failed, meeting to pull up bottom filter of Left/Right Join
> ---
>
> Key: CALCITE-3935
> URL: https://issues.apache.org/jira/browse/CALCITE-3935
> Project: Calcite
> Issue Type: Bug
>Reporter: Xurenhe
>Assignee: Xurenhe
>Priority: Major
> Labels: pull-request-available
> Attachments: Jietu20200417-200532.png
>
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> Hi all.
> `SubstitutionVisitor` support more join_type in some rules of `Join`.
> Now `SubstitutionVisitor` only support join type of `INNER`, when pulling up
> bottom filters of join.
> It doesn't work as follows.
> {code:java}
> @Test public void testJoinOnLeftProjectWithFilterToJoin() {
> String mv = ""
> + "select \"emps\".\"empid\", \"depts\".\"name\",
> \"emps\".\"salary\"\n" +
> "from \"emps\"\n" +
> "left join \"depts\"\n" +
> "on \"emps\".\"deptno\" = \"depts\".\"deptno\"\n"
> + "where \"emps\".\"empid\" > 10";
> String query = ""
> + "select \"emps\".\"empid\", \"depts\".\"name\",
> \"emps\".\"salary\"\n" +
> "from \"emps\"\n" +
> "left join \"depts\"\n" +
> "on \"emps\".\"deptno\" = \"depts\".\"deptno\"\n"
> + "where \"emps\".\"empid\" > 40";
> sql(mv, query).withOnlyBySubstitution(true).ok();
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4584) Using function in partition by list of over window cause converting exception
[
https://issues.apache.org/jira/browse/CALCITE-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17409266#comment-17409266
]
Wang Yanlin commented on CALCITE-4584:
--
Fixed in
https://github.com/apache/calcite/commit/51c0d925489b57319502ffdebbdd93b6fe4e1e8a
> Using function in partition by list of over window cause converting exception
> -
>
> Key: CALCITE-4584
> URL: https://issues.apache.org/jira/browse/CALCITE-4584
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Major
> Labels: pull-request-available
> Time Spent: 50m
> Remaining Estimate: 0h
>
> When try to using function expr in the partition by list of over window in
> sql, got
> {noformat}
> java.lang.UnsupportedOperationException: class
> org.apache.calcite.sql.SqlBasicCall: CHAR_LENGTH(`ENAME`)
> {noformat}
> The stack trace is as follow
> {noformat}
> java.lang.RuntimeException: while converting CHAR_LENGTH(`EMP`.`ENAME`)
> at
> org.apache.calcite.sql2rel.ReflectiveConvertletTable.lambda$registerOpTypeMethod$3(ReflectiveConvertletTable.java:145)
> at
> org.apache.calcite.sql2rel.SqlNodeToRexConverterImpl.convertCall(SqlNodeToRexConverterImpl.java:62)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:5232)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:4486)
> at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:161)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:5088)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertOver(SqlToRelConverter.java:2037)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.access$2000(SqlToRelConverter.java:224)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:5081)
> at
> org.apache.calcite.sql2rel.StandardConvertletTable.lambda$new$9(StandardConvertletTable.java:209)
> at
> org.apache.calcite.sql2rel.SqlNodeToRexConverterImpl.convertCall(SqlNodeToRexConverterImpl.java:62)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:5232)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:4486)
> at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:161)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:5088)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectList(SqlToRelConverter.java:4327)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:707)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:664)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3538)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:589)
> at
> org.apache.calcite.test.SqlToRelTestBase$TesterImpl.convertSqlToRel(SqlToRelTestBase.java:638)
> at
> org.apache.calcite.test.SqlToRelTestBase$TesterImpl.assertConvertsTo(SqlToRelTestBase.java:799)
> at
> org.apache.calcite.test.SqlToRelConverterTest.testFunctionExprInOver(SqlToRelConverterTest.java:4196)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:675)
> at
> org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:125)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:139)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:131)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:81)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(ExecutableInvoker.java:115)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker.lambda$invoke$0(ExecutableInvoker.java:105)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedIn
[jira] [Resolved] (CALCITE-4584) Using function in partition by list of over window cause converting exception
[
https://issues.apache.org/jira/browse/CALCITE-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin resolved CALCITE-4584.
--
Resolution: Fixed
> Using function in partition by list of over window cause converting exception
> -
>
> Key: CALCITE-4584
> URL: https://issues.apache.org/jira/browse/CALCITE-4584
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Major
> Labels: pull-request-available
> Time Spent: 50m
> Remaining Estimate: 0h
>
> When try to using function expr in the partition by list of over window in
> sql, got
> {noformat}
> java.lang.UnsupportedOperationException: class
> org.apache.calcite.sql.SqlBasicCall: CHAR_LENGTH(`ENAME`)
> {noformat}
> The stack trace is as follow
> {noformat}
> java.lang.RuntimeException: while converting CHAR_LENGTH(`EMP`.`ENAME`)
> at
> org.apache.calcite.sql2rel.ReflectiveConvertletTable.lambda$registerOpTypeMethod$3(ReflectiveConvertletTable.java:145)
> at
> org.apache.calcite.sql2rel.SqlNodeToRexConverterImpl.convertCall(SqlNodeToRexConverterImpl.java:62)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:5232)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:4486)
> at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:161)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:5088)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertOver(SqlToRelConverter.java:2037)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.access$2000(SqlToRelConverter.java:224)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:5081)
> at
> org.apache.calcite.sql2rel.StandardConvertletTable.lambda$new$9(StandardConvertletTable.java:209)
> at
> org.apache.calcite.sql2rel.SqlNodeToRexConverterImpl.convertCall(SqlNodeToRexConverterImpl.java:62)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:5232)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:4486)
> at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:161)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:5088)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectList(SqlToRelConverter.java:4327)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:707)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:664)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3538)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:589)
> at
> org.apache.calcite.test.SqlToRelTestBase$TesterImpl.convertSqlToRel(SqlToRelTestBase.java:638)
> at
> org.apache.calcite.test.SqlToRelTestBase$TesterImpl.assertConvertsTo(SqlToRelTestBase.java:799)
> at
> org.apache.calcite.test.SqlToRelConverterTest.testFunctionExprInOver(SqlToRelConverterTest.java:4196)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:675)
> at
> org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:125)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:139)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:131)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:81)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(ExecutableInvoker.java:115)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker.lambda$invoke$0(ExecutableInvoker.java:105)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:104)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorCha
[jira] [Resolved] (CALCITE-4734) Materialization-Failed, when meeting same projs in mv.
[
https://issues.apache.org/jira/browse/CALCITE-4734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin resolved CALCITE-4734.
--
Resolution: Fixed
> Materialization-Failed, when meeting same projs in mv.
> --
>
> Key: CALCITE-4734
> URL: https://issues.apache.org/jira/browse/CALCITE-4734
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Xurenhe
>Priority: Critical
> Labels: pull-request-available
> Attachments: image-2021-08-13-11-43-54-035.png,
> image-2021-08-13-11-44-09-504.png
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Some user may define some not beautiful mv, but these mv should be worked for
> rewriting query.
> For example:
> {code:java}
> @Test void testMoreSameExprInMv() {
> final String mv = ""
> + "select \"empid\", \"deptno\", sum(\"empid\") as s1, sum(\"empid\")
> as s2, count(*) as c\n"
> + "from \"emps\" group by \"empid\", \"deptno\"";
> final String query = ""
> + "select sum(\"empid\"), count(*) from \"emps\" group by \"empid\",
> \"deptno\"";
> sql(mv, query).ok();
> }
> {code}
> I try debug code to solve this problem.
> I find some bug in
> {code:java}
> org.apache.calcite.plan.SubstitutionVisitor#getRexShuttle
> {code}
> !image-2021-08-13-11-43-54-035.png|thumbnail!
> !image-2021-08-13-11-44-09-504.png|thumbnail!
> PR: https://github.com/apache/calcite/pull/2484
> Please review, THX.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4734) Materialization-Failed, when meeting same projs in mv.
[
https://issues.apache.org/jira/browse/CALCITE-4734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17407867#comment-17407867
]
Wang Yanlin commented on CALCITE-4734:
--
Fixed in
[https://github.com/apache/calcite/commit/4b4bb7ff3fd5ca4d2d3e7e8f9eab3df0cee49d76,]
thanks [~wojustme]
> Materialization-Failed, when meeting same projs in mv.
> --
>
> Key: CALCITE-4734
> URL: https://issues.apache.org/jira/browse/CALCITE-4734
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Xurenhe
>Priority: Critical
> Labels: pull-request-available
> Attachments: image-2021-08-13-11-43-54-035.png,
> image-2021-08-13-11-44-09-504.png
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Some user may define some not beautiful mv, but these mv should be worked for
> rewriting query.
> For example:
> {code:java}
> @Test void testMoreSameExprInMv() {
> final String mv = ""
> + "select \"empid\", \"deptno\", sum(\"empid\") as s1, sum(\"empid\")
> as s2, count(*) as c\n"
> + "from \"emps\" group by \"empid\", \"deptno\"";
> final String query = ""
> + "select sum(\"empid\"), count(*) from \"emps\" group by \"empid\",
> \"deptno\"";
> sql(mv, query).ok();
> }
> {code}
> I try debug code to solve this problem.
> I find some bug in
> {code:java}
> org.apache.calcite.plan.SubstitutionVisitor#getRexShuttle
> {code}
> !image-2021-08-13-11-43-54-035.png|thumbnail!
> !image-2021-08-13-11-44-09-504.png|thumbnail!
> PR: https://github.com/apache/calcite/pull/2484
> Please review, THX.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (CALCITE-4584) Using function in partition by list of over window cause converting exception
[
https://issues.apache.org/jira/browse/CALCITE-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin reassigned CALCITE-4584:
Assignee: Wang Yanlin
> Using function in partition by list of over window cause converting exception
> -
>
> Key: CALCITE-4584
> URL: https://issues.apache.org/jira/browse/CALCITE-4584
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When try to using function expr in the partition by list of over window in
> sql, got
> {noformat}
> java.lang.UnsupportedOperationException: class
> org.apache.calcite.sql.SqlBasicCall: CHAR_LENGTH(`ENAME`)
> {noformat}
> The stack trace is as follow
> {noformat}
> java.lang.RuntimeException: while converting CHAR_LENGTH(`EMP`.`ENAME`)
> at
> org.apache.calcite.sql2rel.ReflectiveConvertletTable.lambda$registerOpTypeMethod$3(ReflectiveConvertletTable.java:145)
> at
> org.apache.calcite.sql2rel.SqlNodeToRexConverterImpl.convertCall(SqlNodeToRexConverterImpl.java:62)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:5232)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:4486)
> at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:161)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:5088)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertOver(SqlToRelConverter.java:2037)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.access$2000(SqlToRelConverter.java:224)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:5081)
> at
> org.apache.calcite.sql2rel.StandardConvertletTable.lambda$new$9(StandardConvertletTable.java:209)
> at
> org.apache.calcite.sql2rel.SqlNodeToRexConverterImpl.convertCall(SqlNodeToRexConverterImpl.java:62)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:5232)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:4486)
> at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:161)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:5088)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectList(SqlToRelConverter.java:4327)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:707)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:664)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3538)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:589)
> at
> org.apache.calcite.test.SqlToRelTestBase$TesterImpl.convertSqlToRel(SqlToRelTestBase.java:638)
> at
> org.apache.calcite.test.SqlToRelTestBase$TesterImpl.assertConvertsTo(SqlToRelTestBase.java:799)
> at
> org.apache.calcite.test.SqlToRelConverterTest.testFunctionExprInOver(SqlToRelConverterTest.java:4196)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:675)
> at
> org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:125)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:139)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:131)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:81)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(ExecutableInvoker.java:115)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker.lambda$invoke$0(ExecutableInvoker.java:105)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:104)
> at
> org.junit.jupiter.engine.execution.InvocationInter
[jira] [Created] (CALCITE-4584) Using function in partition by list of over window cause converting exception
Wang Yanlin created CALCITE-4584:
Summary: Using function in partition by list of over window cause
converting exception
Key: CALCITE-4584
URL: https://issues.apache.org/jira/browse/CALCITE-4584
Project: Calcite
Issue Type: Bug
Reporter: Wang Yanlin
When try to using function expr in the partition by list of over window in sql,
got
{noformat}
java.lang.UnsupportedOperationException: class
org.apache.calcite.sql.SqlBasicCall: CHAR_LENGTH(`ENAME`)
{noformat}
The stack trace is as follow
{noformat}
java.lang.RuntimeException: while converting CHAR_LENGTH(`EMP`.`ENAME`)
at
org.apache.calcite.sql2rel.ReflectiveConvertletTable.lambda$registerOpTypeMethod$3(ReflectiveConvertletTable.java:145)
at
org.apache.calcite.sql2rel.SqlNodeToRexConverterImpl.convertCall(SqlNodeToRexConverterImpl.java:62)
at
org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:5232)
at
org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:4486)
at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:161)
at
org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:5088)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertOver(SqlToRelConverter.java:2037)
at
org.apache.calcite.sql2rel.SqlToRelConverter.access$2000(SqlToRelConverter.java:224)
at
org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:5081)
at
org.apache.calcite.sql2rel.StandardConvertletTable.lambda$new$9(StandardConvertletTable.java:209)
at
org.apache.calcite.sql2rel.SqlNodeToRexConverterImpl.convertCall(SqlNodeToRexConverterImpl.java:62)
at
org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:5232)
at
org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:4486)
at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:161)
at
org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:5088)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectList(SqlToRelConverter.java:4327)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:707)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:664)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3538)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:589)
at
org.apache.calcite.test.SqlToRelTestBase$TesterImpl.convertSqlToRel(SqlToRelTestBase.java:638)
at
org.apache.calcite.test.SqlToRelTestBase$TesterImpl.assertConvertsTo(SqlToRelTestBase.java:799)
at
org.apache.calcite.test.SqlToRelConverterTest.testFunctionExprInOver(SqlToRelConverterTest.java:4196)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:675)
at
org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:125)
at
org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:139)
at
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:131)
at
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:81)
at
org.junit.jupiter.engine.execution.ExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(ExecutableInvoker.java:115)
at
org.junit.jupiter.engine.execution.ExecutableInvoker.lambda$invoke$0(ExecutableInvoker.java:105)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:104)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:62)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:43)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:35)
at
org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:104)
at
org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(Exe
[jira] [Updated] (CALCITE-4376) Materialized view recognition fails when target project different columns with GROUP BY
[
https://issues.apache.org/jira/browse/CALCITE-4376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin updated CALCITE-4376:
-
Summary: Materialized view recognition fails when target project different
columns with GROUP BY (was: Materialized view recognition fails when target
project different column sequence with GROUP BY)
> Materialized view recognition fails when target project different columns
> with GROUP BY
> ---
>
> Key: CALCITE-4376
> URL: https://issues.apache.org/jira/browse/CALCITE-4376
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When target project a different column sequence with group by, materialized
> view recognition will fail, see the case below
> {noformat}
> @Test void testDifferentGroupBySequence() {
> final String mv = "" +
> "select \"deptno\", \"name\" from ("
> + "select \"name\", \"deptno\", \"commission\"\n"
> + "from \"emps\"\n"
> + " group by \"name\", \"deptno\", \"commission\") t";
> final String query = ""
> + "select \"deptno\", \"name\"\n"
> + "from \"emps\"\n"
> + "group by \"deptno\", \"name\"";
> sql(mv, query).withChecker(
> resultContains(""
> + "EnumerableTableScan(table=[[hr, MV0]])")).ok();
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4376) Materialized view recognition fails when target project different column sequence with GROUP BY
[
https://issues.apache.org/jira/browse/CALCITE-4376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin updated CALCITE-4376:
-
Description:
When target project a different column sequence with group by, materialized
view recognition will fail, see the case below
{noformat}
@Test void testDifferentGroupBySequence() {
final String mv = "" +
"select \"deptno\", \"name\" from ("
+ "select \"name\", \"deptno\", \"commission\"\n"
+ "from \"emps\"\n"
+ " group by \"name\", \"deptno\", \"commission\") t";
final String query = ""
+ "select \"deptno\", \"name\"\n"
+ "from \"emps\"\n"
+ "group by \"deptno\", \"name\"";
sql(mv, query).withChecker(
resultContains(""
+ "EnumerableTableScan(table=[[hr, MV0]])")).ok();
}
{noformat}
was:
When target project a different column sequence with group by, materialized
view recognition will fail, see the case below
{noformat}
@Test void testDifferentGroupBySequence() {
final String mv = "" +
"select \"deptno\", \"name\" from ("
+ "select \"name\", \"deptno\", \"commission\"\n"
+ "from \"emps\"\n"
+ " group by \"name\", \"deptno\", \"commission\") t";
final String query = ""
+ "select \"deptno\", \"name\"\n"
+ "from \"emps\"\n"
+ "group by \"deptno\", \"name\"";
sql(mv, query).withChecker(
resultContains(""
+ "EnumerableTableScan(table=[[hr, MV0]])")).ok();
}
{noformat}
After the call of "AggregateOnCalcToAggregateUnifyRule", the result query is
{noformat}
Holder
Calc(program: (expr#0..1=[{inputs}], deptno=[$t1], name=[$t0]))
Aggregate(groupSet: {0, 1}, groupSets: [{0, 1}], calls: [])
Aggregate(groupSet: {0, 1, 2}, groupSets: [{0, 1, 2}], calls: [])
Calc(program: (expr#0..4=[{inputs}], name=[$t2], deptno=[$t1],
commission=[$t4]))
Scan(table: [hr, emps])
{noformat}
, and the target is
{noformat}
Calc(program: (expr#0..2=[{inputs}], deptno=[$t1], name=[$t0]))
Aggregate(groupSet: {0, 1, 2}, groupSets: [{0, 1, 2}], calls: [])
Calc(program: (expr#0..4=[{inputs}], name=[$t2], deptno=[$t1],
commission=[$t4]))
Scan(table: [hr, emps])
{noformat}
There is no match for
{noformat}
query descendant: Aggregate(groupSet: {1, 2}, groupSets: [{1, 2}], calls: [])
target descendant: Calc(program: (expr#0..2=[{inputs}], deptno=[$t1],
name=[$t0]))
{noformat}
and the recognition fails. Maybe always add a calc in the call result of
"AggregateOnCalcToAggregateUnifyRule", make the call result like this
{noformat}
Holder
Calc(program: (expr#0..1=[{inputs}], deptno=[$t1], name=[$t0]))
Aggregate(groupSet: {0, 1}, groupSets: [{0, 1}], calls: [])
Calc () // always add a calc here
Aggregate(groupSet: {0, 1, 2}, groupSets: [{0, 1, 2}], calls: [])
Calc(program: (expr#0..4=[{inputs}], name=[$t2], deptno=[$t1],
commission=[$t4]))
Scan(table: [hr, emps])
{noformat}
> Materialized view recognition fails when target project different column
> sequence with GROUP BY
> ---
>
> Key: CALCITE-4376
> URL: https://issues.apache.org/jira/browse/CALCITE-4376
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Major
>
> When target project a different column sequence with group by, materialized
> view recognition will fail, see the case below
> {noformat}
> @Test void testDifferentGroupBySequence() {
> final String mv = "" +
> "select \"deptno\", \"name\" from ("
> + "select \"name\", \"deptno\", \"commission\"\n"
> + "from \"emps\"\n"
> + " group by \"name\", \"deptno\", \"commission\") t";
> final String query = ""
> + "select \"deptno\", \"name\"\n"
> + "from \"emps\"\n"
> + "group by \"deptno\", \"name\"";
> sql(mv, query).withChecker(
> resultContains(""
> + "EnumerableTableScan(table=[[hr, MV0]])")).ok();
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4376) Materialized view recognition fails when target project different column sequence with GROUP BY
[
https://issues.apache.org/jira/browse/CALCITE-4376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin updated CALCITE-4376:
-
Description:
When target project a different column sequence with group by, materialized
view recognition will fail, see the case below
{noformat}
@Test void testDifferentGroupBySequence() {
final String mv = "" +
"select \"deptno\", \"name\" from ("
+ "select \"name\", \"deptno\", \"commission\"\n"
+ "from \"emps\"\n"
+ " group by \"name\", \"deptno\", \"commission\") t";
final String query = ""
+ "select \"deptno\", \"name\"\n"
+ "from \"emps\"\n"
+ "group by \"deptno\", \"name\"";
sql(mv, query).withChecker(
resultContains(""
+ "EnumerableTableScan(table=[[hr, MV0]])")).ok();
}
{noformat}
After the call of "AggregateOnCalcToAggregateUnifyRule", the result query is
{noformat}
Holder
Calc(program: (expr#0..1=[{inputs}], deptno=[$t1], name=[$t0]))
Aggregate(groupSet: {0, 1}, groupSets: [{0, 1}], calls: [])
Aggregate(groupSet: {0, 1, 2}, groupSets: [{0, 1, 2}], calls: [])
Calc(program: (expr#0..4=[{inputs}], name=[$t2], deptno=[$t1],
commission=[$t4]))
Scan(table: [hr, emps])
{noformat}
, and the target is
{noformat}
Calc(program: (expr#0..2=[{inputs}], deptno=[$t1], name=[$t0]))
Aggregate(groupSet: {0, 1, 2}, groupSets: [{0, 1, 2}], calls: [])
Calc(program: (expr#0..4=[{inputs}], name=[$t2], deptno=[$t1],
commission=[$t4]))
Scan(table: [hr, emps])
{noformat}
There is no match for
{noformat}
query descendant: Aggregate(groupSet: {1, 2}, groupSets: [{1, 2}], calls: [])
target descendant: Calc(program: (expr#0..2=[{inputs}], deptno=[$t1],
name=[$t0]))
{noformat}
and the recognition fails. Maybe always add a calc in the call result of
"AggregateOnCalcToAggregateUnifyRule", make the call result like this
{noformat}
Holder
Calc(program: (expr#0..1=[{inputs}], deptno=[$t1], name=[$t0]))
Aggregate(groupSet: {0, 1}, groupSets: [{0, 1}], calls: [])
Calc () // always add a calc here
Aggregate(groupSet: {0, 1, 2}, groupSets: [{0, 1, 2}], calls: [])
Calc(program: (expr#0..4=[{inputs}], name=[$t2], deptno=[$t1],
commission=[$t4]))
Scan(table: [hr, emps])
{noformat}
was:
When target project a different column sequence with group by, materialized
view recognition will fail, see the case below
{noformat}
@Test void test() {
final String mv = "" +
"select \"deptno\", \"name\" from ("
+ "select \"name\", \"deptno\", \"commission\" as cnt\n"
+ "from \"emps\"\n"
+ " group by \"name\", \"deptno\", \"commission\") t";
final String query = ""
+ "select \"deptno\", \"commission\" as cnt\n"
+ "from \"emps\"\n"
+ "group by \"deptno\", \"commission\"";
sql(mv, query).withChecker(
resultContains(""
+ "EnumerableTableScan(table=[[hr, MV0]])")).ok();
}
{noformat}
After the call of "AggregateOnCalcToAggregateUnifyRule", the result query is
{noformat}
Holder
Aggregate(groupSet: {1, 2}, groupSets: [{1, 2}], calls: [])
Aggregate(groupSet: {0, 1, 2}, groupSets: [{0, 1, 2}], calls: [])
Calc(program: (expr#0..4=[{inputs}], name=[$t2], deptno=[$t1],
commission=[$t4]))
Scan(table: [hr, emps])
{noformat}
, and the target is
{noformat}
Calc(program: (expr#0..2=[{inputs}], deptno=[$t1], name=[$t0]))
Aggregate(groupSet: {0, 1, 2}, groupSets: [{0, 1, 2}], calls: [])
Calc(program: (expr#0..4=[{inputs}], name=[$t2], deptno=[$t1],
commission=[$t4]))
Scan(table: [hr, emps])
{noformat}
There is no match for
{noformat}
query descendant: Aggregate(groupSet: {1, 2}, groupSets: [{1, 2}], calls: [])
target descendant: Calc(program: (expr#0..2=[{inputs}], deptno=[$t1],
name=[$t0]))
{noformat}
and the recognition fails. Maybe always add a calc in the call result of
"AggregateOnCalcToAggregateUnifyRule", make the call result like this
{noformat}
Holder
Aggregate(groupSet: {1, 2}, groupSets: [{1, 2}], calls: [])
Calc () // always add a calc here
Aggregate(groupSet: {0, 1, 2}, groupSets: [{0, 1, 2}], calls: [])
Calc(program: (expr#0..4=[{inputs}], name=[$t2], deptno=[$t1],
commission=[$t4]))
Scan(table: [hr, emps])
{noformat}
> Materialized view recognition fails when target project different column
> sequence with GROUP BY
> ---
>
> Key: CALCITE-4376
> URL: https://issues.apache.org/jira/browse/CALCITE-4376
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Major
>
> When target project a different column sequence with group by, materialized
> view recognition will fail, see the c
[jira] [Resolved] (CALCITE-4005) Support Calc and SetOp operator in RelMdAllPredicates
[ https://issues.apache.org/jira/browse/CALCITE-4005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wang Yanlin resolved CALCITE-4005. -- Resolution: Fixed Fixed in https://github.com/apache/calcite/commit/99251a51842483bc80688364195a159b740bd53f, thx [~xzh_dz] > Support Calc and SetOp operator in RelMdAllPredicates > - > > Key: CALCITE-4005 > URL: https://issues.apache.org/jira/browse/CALCITE-4005 > Project: Calcite > Issue Type: Wish >Reporter: xzh_dz >Priority: Major > Labels: pull-request-available > Time Spent: 2.5h > Remaining Estimate: 0h > > Support calc operator in RelMdAllPredicates > and also support setOp operator. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CALCITE-4251) Get the origin column, even if it is derived
[
https://issues.apache.org/jira/browse/CALCITE-4251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin resolved CALCITE-4251.
--
Resolution: Fixed
Fixed in
https://github.com/apache/calcite/commit/f3c173c9220a83be0dfa0c80a39b015f384ffcd1,
thx [~xzh_dz]
> Get the origin column, even if it is derived
>
>
> Key: CALCITE-4251
> URL: https://issues.apache.org/jira/browse/CALCITE-4251
> Project: Calcite
> Issue Type: Wish
>Reporter: xzh_dz
>Priority: Major
> Labels: pull-request-available
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> A case:
> {code:java}
> final String sql1 = ""
> + "select empno, sum(sal) as all_sal\n"
> + "from emp\n"
> + "group by empno";
> {code}
> When i try to get the `all_sal` origin column field,it will return null and
> it is derived. we always get the origin column although it is derived. We
> should overload this method and determine whether the column is derived by
> setting parameters.
> org.apache.calcite.rel.metadata.RelMetadataQuery#getColumnOrigin
> {code:java}
> // code placeholder
> public RelColumnOrigin getColumnOrigin(RelNode rel, int column) {
> final Set origins = getColumnOrigins(rel, column);
> if (origins == null || origins.size() != 1) {
> return null;
> }
> final RelColumnOrigin origin = Iterables.getOnlyElement(origins);
> return origin.isDerived() ? null : origin;
> }
> {code}
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4374) Support materialized view recognition when query distinct aggregate on target GROUP BY column
[
https://issues.apache.org/jira/browse/CALCITE-4374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230322#comment-17230322
]
Wang Yanlin commented on CALCITE-4374:
--
Fixed in Fixed in
https://github.com/apache/calcite/commit/1e6b7425ec20e2bddc6331a21016475a43f9d995,
thx [~xzh_dz]
> Support materialized view recognition when query distinct aggregate on target
> GROUP BY column
> -
>
> Key: CALCITE-4374
> URL: https://issues.apache.org/jira/browse/CALCITE-4374
> Project: Calcite
> Issue Type: Improvement
>Reporter: Wang Yanlin
>Priority: Major
> Labels: pull-request-available
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> When query distinct aggregate on the column, which is in the group by list of
> target.
> Materialized view recognition should success.
> See this case.
> {noformat}
> @Test void testQueryDistinctColumnInTargetGroupByList() {
> final String mv = ""
> + "select \"name\", \"deptno\" "
> + "from \"emps\" group by \"name\", \"deptno\"";
> final String query = ""
> + "select \"name\", count(distinct \"deptno\")\n"
> + "from \"emps\" group by \"name\"";
> sql(mv, query).ok();
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CALCITE-4374) Support materialized view recognition when query distinct aggregate on target GROUP BY column
[
https://issues.apache.org/jira/browse/CALCITE-4374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin resolved CALCITE-4374.
--
Resolution: Fixed
> Support materialized view recognition when query distinct aggregate on target
> GROUP BY column
> -
>
> Key: CALCITE-4374
> URL: https://issues.apache.org/jira/browse/CALCITE-4374
> Project: Calcite
> Issue Type: Improvement
>Reporter: Wang Yanlin
>Priority: Major
> Labels: pull-request-available
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> When query distinct aggregate on the column, which is in the group by list of
> target.
> Materialized view recognition should success.
> See this case.
> {noformat}
> @Test void testQueryDistinctColumnInTargetGroupByList() {
> final String mv = ""
> + "select \"name\", \"deptno\" "
> + "from \"emps\" group by \"name\", \"deptno\"";
> final String query = ""
> + "select \"name\", count(distinct \"deptno\")\n"
> + "from \"emps\" group by \"name\"";
> sql(mv, query).ok();
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (CALCITE-4376) Materialized view recognition fails when target project different column sequence with GROUP BY
[
https://issues.apache.org/jira/browse/CALCITE-4376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin reassigned CALCITE-4376:
Assignee: Wang Yanlin
> Materialized view recognition fails when target project different column
> sequence with GROUP BY
> ---
>
> Key: CALCITE-4376
> URL: https://issues.apache.org/jira/browse/CALCITE-4376
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Major
>
> When target project a different column sequence with group by, materialized
> view recognition will fail, see the case below
> {noformat}
> @Test void test() {
> final String mv = "" +
> "select \"deptno\", \"name\" from ("
> + "select \"name\", \"deptno\", \"commission\" as cnt\n"
> + "from \"emps\"\n"
> + " group by \"name\", \"deptno\", \"commission\") t";
> final String query = ""
> + "select \"deptno\", \"commission\" as cnt\n"
> + "from \"emps\"\n"
> + "group by \"deptno\", \"commission\"";
> sql(mv, query).withChecker(
> resultContains(""
> + "EnumerableTableScan(table=[[hr, MV0]])")).ok();
> }
> {noformat}
> After the call of "AggregateOnCalcToAggregateUnifyRule", the result query is
> {noformat}
> Holder
> Aggregate(groupSet: {1, 2}, groupSets: [{1, 2}], calls: [])
> Aggregate(groupSet: {0, 1, 2}, groupSets: [{0, 1, 2}], calls: [])
> Calc(program: (expr#0..4=[{inputs}], name=[$t2], deptno=[$t1],
> commission=[$t4]))
> Scan(table: [hr, emps])
> {noformat}
> , and the target is
> {noformat}
> Calc(program: (expr#0..2=[{inputs}], deptno=[$t1], name=[$t0]))
> Aggregate(groupSet: {0, 1, 2}, groupSets: [{0, 1, 2}], calls: [])
> Calc(program: (expr#0..4=[{inputs}], name=[$t2], deptno=[$t1],
> commission=[$t4]))
> Scan(table: [hr, emps])
> {noformat}
> There is no match for
> {noformat}
> query descendant: Aggregate(groupSet: {1, 2}, groupSets: [{1, 2}], calls: [])
> target descendant: Calc(program: (expr#0..2=[{inputs}], deptno=[$t1],
> name=[$t0]))
> {noformat}
> and the recognition fails. Maybe always add a calc in the call result of
> "AggregateOnCalcToAggregateUnifyRule", make the call result like this
> {noformat}
> Holder
> Aggregate(groupSet: {1, 2}, groupSets: [{1, 2}], calls: [])
> Calc () // always add a calc here
> Aggregate(groupSet: {0, 1, 2}, groupSets: [{0, 1, 2}], calls: [])
> Calc(program: (expr#0..4=[{inputs}], name=[$t2], deptno=[$t1],
> commission=[$t4]))
> Scan(table: [hr, emps])
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4376) Materialized view recognition fails when target project different column sequence with GROUP BY
[
https://issues.apache.org/jira/browse/CALCITE-4376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin updated CALCITE-4376:
-
Description:
When target project a different column sequence with group by, materialized
view recognition will fail, see the case below
{noformat}
@Test void test() {
final String mv = "" +
"select \"deptno\", \"name\" from ("
+ "select \"name\", \"deptno\", \"commission\" as cnt\n"
+ "from \"emps\"\n"
+ " group by \"name\", \"deptno\", \"commission\") t";
final String query = ""
+ "select \"deptno\", \"commission\" as cnt\n"
+ "from \"emps\"\n"
+ "group by \"deptno\", \"commission\"";
sql(mv, query).withChecker(
resultContains(""
+ "EnumerableTableScan(table=[[hr, MV0]])")).ok();
}
{noformat}
After the call of "AggregateOnCalcToAggregateUnifyRule", the result query is
{noformat}
Holder
Aggregate(groupSet: {1, 2}, groupSets: [{1, 2}], calls: [])
Aggregate(groupSet: {0, 1, 2}, groupSets: [{0, 1, 2}], calls: [])
Calc(program: (expr#0..4=[{inputs}], name=[$t2], deptno=[$t1],
commission=[$t4]))
Scan(table: [hr, emps])
{noformat}
, and the target is
{noformat}
Calc(program: (expr#0..2=[{inputs}], deptno=[$t1], name=[$t0]))
Aggregate(groupSet: {0, 1, 2}, groupSets: [{0, 1, 2}], calls: [])
Calc(program: (expr#0..4=[{inputs}], name=[$t2], deptno=[$t1],
commission=[$t4]))
Scan(table: [hr, emps])
{noformat}
There is no match for
{noformat}
query descendant: Aggregate(groupSet: {1, 2}, groupSets: [{1, 2}], calls: [])
target descendant: Calc(program: (expr#0..2=[{inputs}], deptno=[$t1],
name=[$t0]))
{noformat}
and the recognition fails. Maybe always add a calc in the call result of
"AggregateOnCalcToAggregateUnifyRule", make the call result like this
{noformat}
Holder
Aggregate(groupSet: {1, 2}, groupSets: [{1, 2}], calls: [])
Calc () // always add a calc here
Aggregate(groupSet: {0, 1, 2}, groupSets: [{0, 1, 2}], calls: [])
Calc(program: (expr#0..4=[{inputs}], name=[$t2], deptno=[$t1],
commission=[$t4]))
Scan(table: [hr, emps])
{noformat}
was:When
> Materialized view recognition fails when target project different column
> sequence with GROUP BY
> ---
>
> Key: CALCITE-4376
> URL: https://issues.apache.org/jira/browse/CALCITE-4376
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Priority: Major
>
> When target project a different column sequence with group by, materialized
> view recognition will fail, see the case below
> {noformat}
> @Test void test() {
> final String mv = "" +
> "select \"deptno\", \"name\" from ("
> + "select \"name\", \"deptno\", \"commission\" as cnt\n"
> + "from \"emps\"\n"
> + " group by \"name\", \"deptno\", \"commission\") t";
> final String query = ""
> + "select \"deptno\", \"commission\" as cnt\n"
> + "from \"emps\"\n"
> + "group by \"deptno\", \"commission\"";
> sql(mv, query).withChecker(
> resultContains(""
> + "EnumerableTableScan(table=[[hr, MV0]])")).ok();
> }
> {noformat}
> After the call of "AggregateOnCalcToAggregateUnifyRule", the result query is
> {noformat}
> Holder
> Aggregate(groupSet: {1, 2}, groupSets: [{1, 2}], calls: [])
> Aggregate(groupSet: {0, 1, 2}, groupSets: [{0, 1, 2}], calls: [])
> Calc(program: (expr#0..4=[{inputs}], name=[$t2], deptno=[$t1],
> commission=[$t4]))
> Scan(table: [hr, emps])
> {noformat}
> , and the target is
> {noformat}
> Calc(program: (expr#0..2=[{inputs}], deptno=[$t1], name=[$t0]))
> Aggregate(groupSet: {0, 1, 2}, groupSets: [{0, 1, 2}], calls: [])
> Calc(program: (expr#0..4=[{inputs}], name=[$t2], deptno=[$t1],
> commission=[$t4]))
> Scan(table: [hr, emps])
> {noformat}
> There is no match for
> {noformat}
> query descendant: Aggregate(groupSet: {1, 2}, groupSets: [{1, 2}], calls: [])
> target descendant: Calc(program: (expr#0..2=[{inputs}], deptno=[$t1],
> name=[$t0]))
> {noformat}
> and the recognition fails. Maybe always add a calc in the call result of
> "AggregateOnCalcToAggregateUnifyRule", make the call result like this
> {noformat}
> Holder
> Aggregate(groupSet: {1, 2}, groupSets: [{1, 2}], calls: [])
> Calc () // always add a calc here
> Aggregate(groupSet: {0, 1, 2}, groupSets: [{0, 1, 2}], calls: [])
> Calc(program: (expr#0..4=[{inputs}], name=[$t2], deptno=[$t1],
> commission=[$t4]))
> Scan(table: [hr, emps])
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4376) Materialized view recognition fails when target project different column sequence with GROUP BY
[ https://issues.apache.org/jira/browse/CALCITE-4376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wang Yanlin updated CALCITE-4376: - Summary: Materialized view recognition fails when target project different column sequence with GROUP BY (was: Materialized view recognition fails when target output different column sequence with GROUP BY) > Materialized view recognition fails when target project different column > sequence with GROUP BY > --- > > Key: CALCITE-4376 > URL: https://issues.apache.org/jira/browse/CALCITE-4376 > Project: Calcite > Issue Type: Bug >Reporter: Wang Yanlin >Priority: Major > > When -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4376) Materialized view recognition fails when target output different column sequence with GROUP BY
[ https://issues.apache.org/jira/browse/CALCITE-4376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wang Yanlin updated CALCITE-4376: - Description: When > Materialized view recognition fails when target output different column > sequence with GROUP BY > -- > > Key: CALCITE-4376 > URL: https://issues.apache.org/jira/browse/CALCITE-4376 > Project: Calcite > Issue Type: Bug >Reporter: Wang Yanlin >Priority: Major > > When -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-4376) Materialized view recognition fails when target output different column sequence with GROUP BY
Wang Yanlin created CALCITE-4376: Summary: Materialized view recognition fails when target output different column sequence with GROUP BY Key: CALCITE-4376 URL: https://issues.apache.org/jira/browse/CALCITE-4376 Project: Calcite Issue Type: Bug Reporter: Wang Yanlin -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CALCITE-4273) Support get expression lineage for Calc
[ https://issues.apache.org/jira/browse/CALCITE-4273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wang Yanlin resolved CALCITE-4273. -- Resolution: Fixed > Support get expression lineage for Calc > --- > > Key: CALCITE-4273 > URL: https://issues.apache.org/jira/browse/CALCITE-4273 > Project: Calcite > Issue Type: Improvement >Reporter: Wang Yanlin >Assignee: Wang Yanlin >Priority: Minor > Labels: pull-request-available > Time Spent: 2h 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4273) Support get expression lineage for Calc
[ https://issues.apache.org/jira/browse/CALCITE-4273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17225746#comment-17225746 ] Wang Yanlin commented on CALCITE-4273: -- Fixed in https://github.com/apache/calcite/commit/2e9edae7fc57ab9c9c7c097008724ac99a1791a3 > Support get expression lineage for Calc > --- > > Key: CALCITE-4273 > URL: https://issues.apache.org/jira/browse/CALCITE-4273 > Project: Calcite > Issue Type: Improvement >Reporter: Wang Yanlin >Assignee: Wang Yanlin >Priority: Minor > Labels: pull-request-available > Time Spent: 2h 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (CALCITE-4373) Count(distinct Col) materialized view recognition failed
[
https://issues.apache.org/jira/browse/CALCITE-4373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin closed CALCITE-4373.
Resolution: Duplicate
Same with https://issues.apache.org/jira/browse/CALCITE-4374
> Count(distinct Col) materialized view recognition failed
>
>
> Key: CALCITE-4373
> URL: https://issues.apache.org/jira/browse/CALCITE-4373
> Project: Calcite
> Issue Type: Wish
>Reporter: xzh_dz
>Priority: Major
> Attachments: image-2020-11-03-10-56-57-804.png
>
>
>
> {code:java}
> org.apache.calcite.test.MaterializedViewSubstitutionVisitorTest
> // code placeholder
> @Test void testCountDistinctInAgg() {
> final String mv = ""
> + "select \"name\", \"commission\", \"deptno\"\n"
> + "from \"emps\" group by \"name\", \"commission\", \"deptno\"";
> final String query = ""
> + "select \"name\", \"commission\", count(distinct \"deptno\") as cnt\n"
> + "from \"emps\" group by \"name\", \"commission\"";
> sql(mv, query).withChecker(
> resultContains(""
> + "LogicalCalc(expr#0..1=[{inputs}], expr#2=['hello':VARCHAR],
> expr#3=[CAST($t0)"
> + ":VARCHAR], expr#4=[=($t2, $t3)], CNT=[$t1], $condition=[$t4])\n"
> + " EnumerableTableScan(table=[[hr, MV0]])")).ok();
> }
> {code}
>
>
> Error:
> !image-2020-11-03-10-56-57-804.png|width=511,height=99!
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4374) Support materialized view recognition when query distinct aggregate on target GROUP BY column
[
https://issues.apache.org/jira/browse/CALCITE-4374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin updated CALCITE-4374:
-
Description:
When query distinct aggregate on the column, which is in the group by list of
target.
Materialized view recognition should success.
See this case.
{noformat}
@Test void testQueryDistinctColumnInTargetGroupByList() {
final String mv = ""
+ "select \"name\", \"deptno\" "
+ "from \"emps\" group by \"name\", \"deptno\"";
final String query = ""
+ "select \"name\", count(distinct \"deptno\")\n"
+ "from \"emps\" group by \"name\"";
sql(mv, query).ok();
}
{noformat}
was:
When query distinct aggregate on the column, which is in the group by list of
target.
Ma
{noformat}
@Test void testQueryDistinctColumnInTargetGroupByList() {
final String mv = ""
+ "select \"name\", \"deptno\" as cnt "
+ "from \"emps\" group by \"name\", \"deptno\"";
final String query = ""
+ "select \"name\", count(distinct \"deptno\")\n"
+ "from \"emps\" group by \"name\"";
sql(mv, query).ok();
}
{noformat}
> Support materialized view recognition when query distinct aggregate on target
> GROUP BY column
> -
>
> Key: CALCITE-4374
> URL: https://issues.apache.org/jira/browse/CALCITE-4374
> Project: Calcite
> Issue Type: Improvement
>Reporter: Wang Yanlin
>Priority: Major
>
> When query distinct aggregate on the column, which is in the group by list of
> target.
> Materialized view recognition should success.
> See this case.
> {noformat}
> @Test void testQueryDistinctColumnInTargetGroupByList() {
> final String mv = ""
> + "select \"name\", \"deptno\" "
> + "from \"emps\" group by \"name\", \"deptno\"";
> final String query = ""
> + "select \"name\", count(distinct \"deptno\")\n"
> + "from \"emps\" group by \"name\"";
> sql(mv, query).ok();
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4374) Support materialized view recognition when query distinct aggregate on target GROUP BY column
[
https://issues.apache.org/jira/browse/CALCITE-4374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin updated CALCITE-4374:
-
Description:
When query distinct aggregate on the column, which is in the group by list of
target.
Ma
{noformat}
@Test void testQueryDistinctColumnInTargetGroupByList() {
final String mv = ""
+ "select \"name\", \"deptno\" as cnt "
+ "from \"emps\" group by \"name\", \"deptno\"";
final String query = ""
+ "select \"name\", count(distinct \"deptno\")\n"
+ "from \"emps\" group by \"name\"";
sql(mv, query).ok();
}
{noformat}
> Support materialized view recognition when query distinct aggregate on target
> GROUP BY column
> -
>
> Key: CALCITE-4374
> URL: https://issues.apache.org/jira/browse/CALCITE-4374
> Project: Calcite
> Issue Type: Improvement
>Reporter: Wang Yanlin
>Priority: Major
>
> When query distinct aggregate on the column, which is in the group by list of
> target.
> Ma
> {noformat}
> @Test void testQueryDistinctColumnInTargetGroupByList() {
> final String mv = ""
> + "select \"name\", \"deptno\" as cnt "
> + "from \"emps\" group by \"name\", \"deptno\"";
> final String query = ""
> + "select \"name\", count(distinct \"deptno\")\n"
> + "from \"emps\" group by \"name\"";
> sql(mv, query).ok();
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-4374) Support materialized view recognition when query distinct aggregate on target GROUP BY column
Wang Yanlin created CALCITE-4374: Summary: Support materialized view recognition when query distinct aggregate on target GROUP BY column Key: CALCITE-4374 URL: https://issues.apache.org/jira/browse/CALCITE-4374 Project: Calcite Issue Type: Improvement Reporter: Wang Yanlin -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (CALCITE-4273) Support get expression lineage for Calc
[ https://issues.apache.org/jira/browse/CALCITE-4273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wang Yanlin reassigned CALCITE-4273: Assignee: Wang Yanlin > Support get expression lineage for Calc > --- > > Key: CALCITE-4273 > URL: https://issues.apache.org/jira/browse/CALCITE-4273 > Project: Calcite > Issue Type: Improvement >Reporter: Wang Yanlin >Assignee: Wang Yanlin >Priority: Minor > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-4273) Support get expression lineage for Calc
Wang Yanlin created CALCITE-4273: Summary: Support get expression lineage for Calc Key: CALCITE-4273 URL: https://issues.apache.org/jira/browse/CALCITE-4273 Project: Calcite Issue Type: Improvement Reporter: Wang Yanlin -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CALCITE-4182) MV recognition fails when query has constant filter for group by list in mv, but without group by
[
https://issues.apache.org/jira/browse/CALCITE-4182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin resolved CALCITE-4182.
--
Resolution: Fixed
> MV recognition fails when query has constant filter for group by list in mv,
> but without group by
> -
>
> Key: CALCITE-4182
> URL: https://issues.apache.org/jira/browse/CALCITE-4182
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Major
> Labels: pull-request-available
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> MV recognition fails when query has constant filter for group by list in mv,
> but has no group by itself.
> {noformat}
> @Test void testConstantFilterInAgg() {
> final String mv = ""
> + "select \"name\", count(distinct \"deptno\") as cnt\n"
> + "from \"emps\" group by \"name\"";
> final String query = ""
> + "select count(distinct \"deptno\") as cnt\n"
> + "from \"emps\" where \"name\" = 'hello'";
> sql(mv, query).ok();
> }
> {noformat}
> This case fails, however we can see that, we can rewrite the query with mv
> like this, suppose *mv* is the name of the table.
> {noformat}
> select cnt from mv where name = 'hello';
> {noformat}
> However, this query has the same semantics with the query in the case, using
> this query for mv recognition, the case will success
> {noformat}
> final String query = ""
> + "select cnt from(\n"
> + " select \"name\", count(distinct \"deptno\") as cnt "
> + " from \"emps\" group by \"name\") t\n"
> + "where \"name\" = 'hello'";
> {noformat}
> But we cannot force users to only write their queries in this way, so maybe
> we need to enhance the mv recognition ability of
> {{AggregateOnCalcToAggregateUnifyRule to cover this case.}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4182) MV recognition fails when query has constant filter for group by list in mv, but without group by
[
https://issues.apache.org/jira/browse/CALCITE-4182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17196989#comment-17196989
]
Wang Yanlin commented on CALCITE-4182:
--
Fixed in
https://github.com/apache/calcite/commit/8250798e4107c639dad122baf868137b35032001
> MV recognition fails when query has constant filter for group by list in mv,
> but without group by
> -
>
> Key: CALCITE-4182
> URL: https://issues.apache.org/jira/browse/CALCITE-4182
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Major
> Labels: pull-request-available
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> MV recognition fails when query has constant filter for group by list in mv,
> but has no group by itself.
> {noformat}
> @Test void testConstantFilterInAgg() {
> final String mv = ""
> + "select \"name\", count(distinct \"deptno\") as cnt\n"
> + "from \"emps\" group by \"name\"";
> final String query = ""
> + "select count(distinct \"deptno\") as cnt\n"
> + "from \"emps\" where \"name\" = 'hello'";
> sql(mv, query).ok();
> }
> {noformat}
> This case fails, however we can see that, we can rewrite the query with mv
> like this, suppose *mv* is the name of the table.
> {noformat}
> select cnt from mv where name = 'hello';
> {noformat}
> However, this query has the same semantics with the query in the case, using
> this query for mv recognition, the case will success
> {noformat}
> final String query = ""
> + "select cnt from(\n"
> + " select \"name\", count(distinct \"deptno\") as cnt "
> + " from \"emps\" group by \"name\") t\n"
> + "where \"name\" = 'hello'";
> {noformat}
> But we cannot force users to only write their queries in this way, so maybe
> we need to enhance the mv recognition ability of
> {{AggregateOnCalcToAggregateUnifyRule to cover this case.}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4182) MV recognition fails when query has constant filter for group by list in mv, but without group by
[
https://issues.apache.org/jira/browse/CALCITE-4182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin updated CALCITE-4182:
-
Description:
MV recognition fails when query has constant filter for group by list in mv,
but has no group by itself.
{noformat}
@Test void testConstantFilterInAgg() {
final String mv = ""
+ "select \"name\", count(distinct \"deptno\") as cnt\n"
+ "from \"emps\" group by \"name\"";
final String query = ""
+ "select count(distinct \"deptno\") as cnt\n"
+ "from \"emps\" where \"name\" = 'hello'";
sql(mv, query).ok();
}
{noformat}
This case fails, however we can see that, we can rewrite the query with mv like
this, suppose *mv* is the name of the table.
{noformat}
select cnt from mv where name = 'hello';
{noformat}
However, this query has the same semantics with the query in the case, using
this query for mv recognition, the case will success
{noformat}
final String query = ""
+ "select cnt from(\n"
+ " select \"name\", count(distinct \"deptno\") as cnt "
+ " from \"emps\" group by \"name\") t\n"
+ "where \"name\" = 'hello'";
{noformat}
But we cannot force users to only write their queries in this way, so maybe we
need to enhance the mv recognition ability of
{{AggregateOnCalcToAggregateUnifyRule to cover this case.}}
was:
MV recognition fails when query has constant filter for group by list in mv,
but has no group by itself.
{noformat}
@Test void testConstantFilterInAgg() {
final String mv = ""
+ "select \"name\", count(distinct \"deptno\") as cnt\n"
+ "from \"emps\" group by \"name\"";
final String query = ""
+ "select count(distinct \"deptno\") as cnt\n"
+ "from \"emps\" where \"name\" = 'hello'";
sql(mv, query).ok();
}
{noformat}
This case fails, however we can see that, we can rewrite the query with mv like
this, suppose *mv* is the name of the table.
{noformat}
select cnt from mv where name = 'hello';
{noformat}
However, this query has the same semantics with the query in the case, using
this query for mv recognition, the case will success
{noformat}
final String query = ""
+ "select cnt from(\n"
+ " select \"name\", count(distinct \"deptno\") as cnt "
+ " from \"emps\" group by \"name\") t\n"
+ "where \"name\" = 'hello'";
{noformat}
But we cannot force users to only write their queries in this way, so maybe we
need a rule to expand aggregate group by list with constant filter condition.
> MV recognition fails when query has constant filter for group by list in mv,
> but without group by
> -
>
> Key: CALCITE-4182
> URL: https://issues.apache.org/jira/browse/CALCITE-4182
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> MV recognition fails when query has constant filter for group by list in mv,
> but has no group by itself.
> {noformat}
> @Test void testConstantFilterInAgg() {
> final String mv = ""
> + "select \"name\", count(distinct \"deptno\") as cnt\n"
> + "from \"emps\" group by \"name\"";
> final String query = ""
> + "select count(distinct \"deptno\") as cnt\n"
> + "from \"emps\" where \"name\" = 'hello'";
> sql(mv, query).ok();
> }
> {noformat}
> This case fails, however we can see that, we can rewrite the query with mv
> like this, suppose *mv* is the name of the table.
> {noformat}
> select cnt from mv where name = 'hello';
> {noformat}
> However, this query has the same semantics with the query in the case, using
> this query for mv recognition, the case will success
> {noformat}
> final String query = ""
> + "select cnt from(\n"
> + " select \"name\", count(distinct \"deptno\") as cnt "
> + " from \"emps\" group by \"name\") t\n"
> + "where \"name\" = 'hello'";
> {noformat}
> But we cannot force users to only write their queries in this way, so maybe
> we need to enhance the mv recognition ability of
> {{AggregateOnCalcToAggregateUnifyRule to cover this case.}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (CALCITE-4182) MV recognition fails when query has constant filter for group by list in mv, but without group by
[
https://issues.apache.org/jira/browse/CALCITE-4182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin reassigned CALCITE-4182:
Assignee: Wang Yanlin
> MV recognition fails when query has constant filter for group by list in mv,
> but without group by
> -
>
> Key: CALCITE-4182
> URL: https://issues.apache.org/jira/browse/CALCITE-4182
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Major
>
> MV recognition fails when query has constant filter for group by list in mv,
> but has no group by itself.
>
> {noformat}
> @Test void testConstantFilterInAgg() {
> final String mv = ""
> + "select \"name\", count(distinct \"deptno\") as cnt\n"
> + "from \"emps\" group by \"name\"";
> final String query = ""
> + "select count(distinct \"deptno\") as cnt\n"
> + "from \"emps\" where \"name\" = 'hello'";
> sql(mv, query).ok();
> }
> {noformat}
> This case fails, however we can see that, we can rewrite the query with mv
> like this, suppose *mv* is the name of the table.
> {noformat}
> select cnt from mv where name = 'hello';
> {noformat}
> However, this query has the same semantics with the query in the case, using
> this query for mv recognition, the case will success
> {noformat}
> final String query = ""
> + "select cnt from(\n"
> + " select \"name\", count(distinct \"deptno\") as cnt "
> + " from \"emps\" group by \"name\") t\n"
> + "where \"name\" = 'hello'";
> {noformat}
> But we cannot force users to only write their queries in this way, so maybe
> we need a rule to expand aggregate group by list with constant filter
> condition.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4182) MV recognition fails when query has constant filter for group by list in mv, but without group by
[
https://issues.apache.org/jira/browse/CALCITE-4182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin updated CALCITE-4182:
-
Description:
MV recognition fails when query has constant filter for group by list in mv,
but has no group by itself.
{noformat}
@Test void testConstantFilterInAgg() {
final String mv = ""
+ "select \"name\", count(distinct \"deptno\") as cnt\n"
+ "from \"emps\" group by \"name\"";
final String query = ""
+ "select count(distinct \"deptno\") as cnt\n"
+ "from \"emps\" where \"name\" = 'hello'";
sql(mv, query).ok();
}
{noformat}
This case fails, however we can see that, we can rewrite the query with mv like
this, suppose *mv* is the name of the table.
{noformat}
select cnt from mv where name = 'hello';
{noformat}
However, this query has the same semantics with the query in the case, using
this query for mv recognition, the case will success
{noformat}
final String query = ""
+ "select cnt from(\n"
+ " select \"name\", count(distinct \"deptno\") as cnt "
+ " from \"emps\" group by \"name\") t\n"
+ "where \"name\" = 'hello'";
{noformat}
But we cannot force users to only write their queries in this way, so maybe we
need a rule to expand aggregate group by list with constant filter condition.
was:
Mv re
{noformat}
@Test void testConstantFilterInAgg() {
final String mv = ""
+ "select \"name\", count(distinct \"deptno\") as cnt\n"
+ "from \"emps\" group by \"name\"";
final String query = ""
+ "select count(distinct \"deptno\") as cnt\n"
+ "from \"emps\" where \"name\" = 'hello'";
sql(mv, query).ok();
}
{noformat}
> MV recognition fails when query has constant filter for group by list in mv,
> but without group by
> -
>
> Key: CALCITE-4182
> URL: https://issues.apache.org/jira/browse/CALCITE-4182
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Priority: Major
>
> MV recognition fails when query has constant filter for group by list in mv,
> but has no group by itself.
>
> {noformat}
> @Test void testConstantFilterInAgg() {
> final String mv = ""
> + "select \"name\", count(distinct \"deptno\") as cnt\n"
> + "from \"emps\" group by \"name\"";
> final String query = ""
> + "select count(distinct \"deptno\") as cnt\n"
> + "from \"emps\" where \"name\" = 'hello'";
> sql(mv, query).ok();
> }
> {noformat}
> This case fails, however we can see that, we can rewrite the query with mv
> like this, suppose *mv* is the name of the table.
> {noformat}
> select cnt from mv where name = 'hello';
> {noformat}
> However, this query has the same semantics with the query in the case, using
> this query for mv recognition, the case will success
> {noformat}
> final String query = ""
> + "select cnt from(\n"
> + " select \"name\", count(distinct \"deptno\") as cnt "
> + " from \"emps\" group by \"name\") t\n"
> + "where \"name\" = 'hello'";
> {noformat}
> But we cannot force users to only write their queries in this way, so maybe
> we need a rule to expand aggregate group by list with constant filter
> condition.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4182) MV recognition fails when query has constant filter for group by list in mv, but without group by
[
https://issues.apache.org/jira/browse/CALCITE-4182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin updated CALCITE-4182:
-
Description:
{noformat}
@Test void testConstantFilterInAgg() {
final String mv = ""
+ "select \"name\", count(distinct \"deptno\") as cnt\n"
+ "from \"emps\" group by \"name\"";
final String query = ""
+ "select count(distinct \"deptno\") as cnt\n"
+ "from \"emps\" where \"name\" = 'hello'";
sql(mv, query).ok();
}
{noformat}
> MV recognition fails when query has constant filter for group by list in mv,
> but without group by
> -
>
> Key: CALCITE-4182
> URL: https://issues.apache.org/jira/browse/CALCITE-4182
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Priority: Major
>
> {noformat}
> @Test void testConstantFilterInAgg() {
> final String mv = ""
> + "select \"name\", count(distinct \"deptno\") as cnt\n"
> + "from \"emps\" group by \"name\"";
> final String query = ""
> + "select count(distinct \"deptno\") as cnt\n"
> + "from \"emps\" where \"name\" = 'hello'";
> sql(mv, query).ok();
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4182) MV recognition fails when query has constant filter for group by list in mv, but without group by
[
https://issues.apache.org/jira/browse/CALCITE-4182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin updated CALCITE-4182:
-
Description:
Mv re
{noformat}
@Test void testConstantFilterInAgg() {
final String mv = ""
+ "select \"name\", count(distinct \"deptno\") as cnt\n"
+ "from \"emps\" group by \"name\"";
final String query = ""
+ "select count(distinct \"deptno\") as cnt\n"
+ "from \"emps\" where \"name\" = 'hello'";
sql(mv, query).ok();
}
{noformat}
was:
{noformat}
@Test void testConstantFilterInAgg() {
final String mv = ""
+ "select \"name\", count(distinct \"deptno\") as cnt\n"
+ "from \"emps\" group by \"name\"";
final String query = ""
+ "select count(distinct \"deptno\") as cnt\n"
+ "from \"emps\" where \"name\" = 'hello'";
sql(mv, query).ok();
}
{noformat}
> MV recognition fails when query has constant filter for group by list in mv,
> but without group by
> -
>
> Key: CALCITE-4182
> URL: https://issues.apache.org/jira/browse/CALCITE-4182
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Priority: Major
>
> Mv re
> {noformat}
> @Test void testConstantFilterInAgg() {
> final String mv = ""
> + "select \"name\", count(distinct \"deptno\") as cnt\n"
> + "from \"emps\" group by \"name\"";
> final String query = ""
> + "select count(distinct \"deptno\") as cnt\n"
> + "from \"emps\" where \"name\" = 'hello'";
> sql(mv, query).ok();
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-4182) MV recognition fails when query has constant filter for group by list in mv, but without group by
Wang Yanlin created CALCITE-4182: Summary: MV recognition fails when query has constant filter for group by list in mv, but without group by Key: CALCITE-4182 URL: https://issues.apache.org/jira/browse/CALCITE-4182 Project: Calcite Issue Type: Bug Reporter: Wang Yanlin -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4177) Throw exception when deserialize SqlOperator fails, do not return null
[
https://issues.apache.org/jira/browse/CALCITE-4177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin updated CALCITE-4177:
-
Description:
Currently, when deserialize a RexNode fails, calcite returns a null value,
causing NPE in somewhere else. So we cannot get any information about the
SqlOperator in the stacktrace. This makes it hard to determine the reason
when deserialize a very long json string.
{noformat}
Caused by: java.lang.NullPointerException
at java.util.Objects.requireNonNull(Objects.java:203)
at
org.apache.calcite.rel.core.AggregateCall.(AggregateCall.java:98)
at
org.apache.calcite.rel.core.AggregateCall.create(AggregateCall.java:198)
at
org.apache.calcite.rel.externalize.RelJsonReader.toAggCall(RelJsonReader.java:289)
at
org.apache.calcite.rel.externalize.RelJsonReader.access$500(RelJsonReader.java:59)
at
org.apache.calcite.rel.externalize.RelJsonReader$2.getAggregateCalls(RelJsonReader.java:172)
at org.apache.calcite.rel.core.Aggregate.(Aggregate.java:220)
at
org.apache.calcite.rel.logical.LogicalAggregate.(LogicalAggregate.java:105)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at
org.apache.calcite.rel.externalize.RelJsonReader.readRel(RelJsonReader.java:264)
at
org.apache.calcite.rel.externalize.RelJsonReader.readRels(RelJsonReader.java:91)
at
org.apache.calcite.rel.externalize.RelJsonReader.read(RelJsonReader.java:85)
at
org.apache.calcite.plan.RelWriterTest.lambda$deserializeAndDumpToTextFormat$6(RelWriterTest.java:894)
at
org.apache.calcite.tools.Frameworks.lambda$withPlanner$0(Frameworks.java:131)
at
org.apache.calcite.prepare.CalcitePrepareImpl.perform(CalcitePrepareImpl.java:914)
at org.apache.calcite.tools.Frameworks.withPrepare(Frameworks.java:180)
... 67 more
{noformat}
Maybe it's better to throw exception instead of return null, adding the name,
kind, and syntax in the error message
was:
Currently, when deserialize a RexNode fails, calcite returns a null value,
causing NPE in somewhere else. So we cannot get any information about the
SqlOperator in the stacktrace. This makes it hard to determine the reason
when deserialize a very long json string.
{noformat}
Caused by: java.lang.NullPointerException
at java.util.Objects.requireNonNull(Objects.java:203)
at
org.apache.calcite.rel.core.AggregateCall.(AggregateCall.java:98)
at
org.apache.calcite.rel.core.AggregateCall.create(AggregateCall.java:198)
at
org.apache.calcite.rel.externalize.RelJsonReader.toAggCall(RelJsonReader.java:289)
at
org.apache.calcite.rel.externalize.RelJsonReader.access$500(RelJsonReader.java:59)
at
org.apache.calcite.rel.externalize.RelJsonReader$2.getAggregateCalls(RelJsonReader.java:172)
at org.apache.calcite.rel.core.Aggregate.(Aggregate.java:220)
at
org.apache.calcite.rel.logical.LogicalAggregate.(LogicalAggregate.java:105)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at
org.apache.calcite.rel.externalize.RelJsonReader.readRel(RelJsonReader.java:264)
at
org.apache.calcite.rel.externalize.RelJsonReader.readRels(RelJsonReader.java:91)
at
org.apache.calcite.rel.externalize.RelJsonReader.read(RelJsonReader.java:85)
at
org.apache.calcite.plan.RelWriterTest.lambda$deserializeAndDumpToTextFormat$6(RelWriterTest.java:894)
at
org.apache.calcite.tools.Frameworks.lambda$withPlanner$0(Frameworks.java:131)
at
org.apache.calcite.prepare.CalcitePrepareImpl.perform(CalcitePrepareImpl.java:914)
at org.apache.calcite.tools.Frameworks.withPrepare(Frameworks.java:180)
... 67 more
{noformat}
Maybe it's better to throw exception instead of return null.
> Throw exception when deserialize SqlOperator fails, do not return null
> --
>
> Key: CALCITE-4177
> URL: https://issues.apache.org/jira/browse/CALCITE-4177
> Project: Calcite
> Issue Type: Improvement
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Minor
>
> Currently, when deserialize a RexNode fails,
[jira] [Updated] (CALCITE-4177) Throw exception when deserialize SqlOperator fails, do not return null
[
https://issues.apache.org/jira/browse/CALCITE-4177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin updated CALCITE-4177:
-
Description:
Currently, when deserialize a RexNode fails, calcite returns a null value,
causing NPE in somewhere else. So we cannot get any information about the
SqlOperator in the stacktrace. This makes it hard to determine the reason
when deserialize a very long json string.
{noformat}
Caused by: java.lang.NullPointerException
at java.util.Objects.requireNonNull(Objects.java:203)
at
org.apache.calcite.rel.core.AggregateCall.(AggregateCall.java:98)
at
org.apache.calcite.rel.core.AggregateCall.create(AggregateCall.java:198)
at
org.apache.calcite.rel.externalize.RelJsonReader.toAggCall(RelJsonReader.java:289)
at
org.apache.calcite.rel.externalize.RelJsonReader.access$500(RelJsonReader.java:59)
at
org.apache.calcite.rel.externalize.RelJsonReader$2.getAggregateCalls(RelJsonReader.java:172)
at org.apache.calcite.rel.core.Aggregate.(Aggregate.java:220)
at
org.apache.calcite.rel.logical.LogicalAggregate.(LogicalAggregate.java:105)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at
org.apache.calcite.rel.externalize.RelJsonReader.readRel(RelJsonReader.java:264)
at
org.apache.calcite.rel.externalize.RelJsonReader.readRels(RelJsonReader.java:91)
at
org.apache.calcite.rel.externalize.RelJsonReader.read(RelJsonReader.java:85)
at
org.apache.calcite.plan.RelWriterTest.lambda$deserializeAndDumpToTextFormat$6(RelWriterTest.java:894)
at
org.apache.calcite.tools.Frameworks.lambda$withPlanner$0(Frameworks.java:131)
at
org.apache.calcite.prepare.CalcitePrepareImpl.perform(CalcitePrepareImpl.java:914)
at org.apache.calcite.tools.Frameworks.withPrepare(Frameworks.java:180)
... 67 more
{noformat}
Maybe it's better to throw exception instead of return null.
was:
Currently, when deserialize a RexNode fails, calcite returns a null value,
causing NPE in somewhere else. So we cannot get any information about the
SqlOperator in the stacktrace. This makes hard to determine the reason when
deserialize a very long json string.
{noformat}
Caused by: java.lang.NullPointerException
at java.util.Objects.requireNonNull(Objects.java:203)
at
org.apache.calcite.rel.core.AggregateCall.(AggregateCall.java:98)
at
org.apache.calcite.rel.core.AggregateCall.create(AggregateCall.java:198)
at
org.apache.calcite.rel.externalize.RelJsonReader.toAggCall(RelJsonReader.java:289)
at
org.apache.calcite.rel.externalize.RelJsonReader.access$500(RelJsonReader.java:59)
at
org.apache.calcite.rel.externalize.RelJsonReader$2.getAggregateCalls(RelJsonReader.java:172)
at org.apache.calcite.rel.core.Aggregate.(Aggregate.java:220)
at
org.apache.calcite.rel.logical.LogicalAggregate.(LogicalAggregate.java:105)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at
org.apache.calcite.rel.externalize.RelJsonReader.readRel(RelJsonReader.java:264)
at
org.apache.calcite.rel.externalize.RelJsonReader.readRels(RelJsonReader.java:91)
at
org.apache.calcite.rel.externalize.RelJsonReader.read(RelJsonReader.java:85)
at
org.apache.calcite.plan.RelWriterTest.lambda$deserializeAndDumpToTextFormat$6(RelWriterTest.java:894)
at
org.apache.calcite.tools.Frameworks.lambda$withPlanner$0(Frameworks.java:131)
at
org.apache.calcite.prepare.CalcitePrepareImpl.perform(CalcitePrepareImpl.java:914)
at org.apache.calcite.tools.Frameworks.withPrepare(Frameworks.java:180)
... 67 more
{noformat}
Maybe it's better to throw exception instead of return null.
> Throw exception when deserialize SqlOperator fails, do not return null
> --
>
> Key: CALCITE-4177
> URL: https://issues.apache.org/jira/browse/CALCITE-4177
> Project: Calcite
> Issue Type: Improvement
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Minor
>
> Currently, when deserialize a RexNode fails, calcite returns a null value,
> causing NPE in somewhere el
[jira] [Created] (CALCITE-4177) Throw exception when deserialize SqlOperator fails, do not return null
Wang Yanlin created CALCITE-4177:
Summary: Throw exception when deserialize SqlOperator fails, do
not return null
Key: CALCITE-4177
URL: https://issues.apache.org/jira/browse/CALCITE-4177
Project: Calcite
Issue Type: Improvement
Reporter: Wang Yanlin
Currently, when deserialize a RexNode fails, calcite returns a null value,
causing NPE in somewhere else. So we cannot get any information about the
SqlOperator in the stacktrace. This makes hard to determine the reason when
deserialize a very long json string.
{noformat}
Caused by: java.lang.NullPointerException
at java.util.Objects.requireNonNull(Objects.java:203)
at
org.apache.calcite.rel.core.AggregateCall.(AggregateCall.java:98)
at
org.apache.calcite.rel.core.AggregateCall.create(AggregateCall.java:198)
at
org.apache.calcite.rel.externalize.RelJsonReader.toAggCall(RelJsonReader.java:289)
at
org.apache.calcite.rel.externalize.RelJsonReader.access$500(RelJsonReader.java:59)
at
org.apache.calcite.rel.externalize.RelJsonReader$2.getAggregateCalls(RelJsonReader.java:172)
at org.apache.calcite.rel.core.Aggregate.(Aggregate.java:220)
at
org.apache.calcite.rel.logical.LogicalAggregate.(LogicalAggregate.java:105)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at
org.apache.calcite.rel.externalize.RelJsonReader.readRel(RelJsonReader.java:264)
at
org.apache.calcite.rel.externalize.RelJsonReader.readRels(RelJsonReader.java:91)
at
org.apache.calcite.rel.externalize.RelJsonReader.read(RelJsonReader.java:85)
at
org.apache.calcite.plan.RelWriterTest.lambda$deserializeAndDumpToTextFormat$6(RelWriterTest.java:894)
at
org.apache.calcite.tools.Frameworks.lambda$withPlanner$0(Frameworks.java:131)
at
org.apache.calcite.prepare.CalcitePrepareImpl.perform(CalcitePrepareImpl.java:914)
at org.apache.calcite.tools.Frameworks.withPrepare(Frameworks.java:180)
... 67 more
{noformat}
Maybe it's better to throw exception instead of return null.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (CALCITE-4177) Throw exception when deserialize SqlOperator fails, do not return null
[
https://issues.apache.org/jira/browse/CALCITE-4177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin reassigned CALCITE-4177:
Assignee: Wang Yanlin
> Throw exception when deserialize SqlOperator fails, do not return null
> --
>
> Key: CALCITE-4177
> URL: https://issues.apache.org/jira/browse/CALCITE-4177
> Project: Calcite
> Issue Type: Improvement
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Minor
>
> Currently, when deserialize a RexNode fails, calcite returns a null value,
> causing NPE in somewhere else. So we cannot get any information about the
> SqlOperator in the stacktrace. This makes hard to determine the reason when
> deserialize a very long json string.
> {noformat}
> Caused by: java.lang.NullPointerException
> at java.util.Objects.requireNonNull(Objects.java:203)
> at
> org.apache.calcite.rel.core.AggregateCall.(AggregateCall.java:98)
> at
> org.apache.calcite.rel.core.AggregateCall.create(AggregateCall.java:198)
> at
> org.apache.calcite.rel.externalize.RelJsonReader.toAggCall(RelJsonReader.java:289)
> at
> org.apache.calcite.rel.externalize.RelJsonReader.access$500(RelJsonReader.java:59)
> at
> org.apache.calcite.rel.externalize.RelJsonReader$2.getAggregateCalls(RelJsonReader.java:172)
> at org.apache.calcite.rel.core.Aggregate.(Aggregate.java:220)
> at
> org.apache.calcite.rel.logical.LogicalAggregate.(LogicalAggregate.java:105)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> org.apache.calcite.rel.externalize.RelJsonReader.readRel(RelJsonReader.java:264)
> at
> org.apache.calcite.rel.externalize.RelJsonReader.readRels(RelJsonReader.java:91)
> at
> org.apache.calcite.rel.externalize.RelJsonReader.read(RelJsonReader.java:85)
> at
> org.apache.calcite.plan.RelWriterTest.lambda$deserializeAndDumpToTextFormat$6(RelWriterTest.java:894)
> at
> org.apache.calcite.tools.Frameworks.lambda$withPlanner$0(Frameworks.java:131)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.perform(CalcitePrepareImpl.java:914)
> at org.apache.calcite.tools.Frameworks.withPrepare(Frameworks.java:180)
> ... 67 more
> {noformat}
> Maybe it's better to throw exception instead of return null.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CALCITE-4022) Support unparse special syntax when operator is INSERT
[
https://issues.apache.org/jira/browse/CALCITE-4022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin resolved CALCITE-4022.
--
Fix Version/s: 1.24.0
Resolution: Fixed
> Support unparse special syntax when operator is INSERT
> --
>
> Key: CALCITE-4022
> URL: https://issues.apache.org/jira/browse/CALCITE-4022
> Project: Calcite
> Issue Type: Wish
>Reporter: xzh_dz
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.24.0
>
> Attachments: image-2020-05-25-17-38-36-009.png
>
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> This exception can be reproduced as below:
> SqlParserTest:
> {code:java}
> @Test void test() throws Exception {
> final String sql = "insert into emps select * from emps";
> final SqlNode sqlNode = getSqlParser(sql).parseStmt();
> final SqlNode sqlNodeVisited = sqlNode.accept(new SqlShuttle() {
> @Override public SqlNode visit(SqlIdentifier identifier) {
> return new SqlIdentifier(identifier.names,
> identifier.getParserPosition());
> }
> });
> System.out.println(sqlNodeVisited.toString());
> }
> {code}
> !image-2020-05-25-17-38-36-009.png!
> Method threw 'java.lang.UnsupportedOperationException' exception. Cannot
> evaluate org.apache.calcite.sql.SqlBasicCall.toString()
> SqlInsert is a SqlSpecialOperator, when `toString` method is called, this
> problem is shown.We can see that `SqlSyntax#SPECIAL#unparse()` hasn't been
> implemented yet.
> exception :
> java.lang.UnsupportedOperationException: class
> org.apache.calcite.sql.SqlSyntax$6: SPECIAL
> at org.apache.calcite.util.Util.needToImplement(Util.java:967)
> at org.apache.calcite.sql.SqlSyntax$6.unparse(SqlSyntax.java:116)
> at org.apache.calcite.sql.SqlOperator.unparse(SqlOperator.java:333)
> at org.apache.calcite.sql.SqlDialect.unparseCall(SqlDialect.java:462)
> at org.apache.calcite.sql.SqlCall.unparse(SqlCall.java:104)
> at org.apache.calcite.sql.SqlNode.toSqlString(SqlNode.java:151)
> at org.apache.calcite.sql.SqlNode.toString(SqlNode.java:126)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4022) Support unparse special syntax when operator is INSERT
[
https://issues.apache.org/jira/browse/CALCITE-4022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17164073#comment-17164073
]
Wang Yanlin commented on CALCITE-4022:
--
Fixed in
[https://github.com/apache/calcite/pull/2014/commits/a45f7b78e4d3891d36abfa9213c609f896601c36],
thanks [~xzh_dz] .
> Support unparse special syntax when operator is INSERT
> --
>
> Key: CALCITE-4022
> URL: https://issues.apache.org/jira/browse/CALCITE-4022
> Project: Calcite
> Issue Type: Wish
>Reporter: xzh_dz
>Priority: Major
> Labels: pull-request-available
> Attachments: image-2020-05-25-17-38-36-009.png
>
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> This exception can be reproduced as below:
> SqlParserTest:
> {code:java}
> @Test void test() throws Exception {
> final String sql = "insert into emps select * from emps";
> final SqlNode sqlNode = getSqlParser(sql).parseStmt();
> final SqlNode sqlNodeVisited = sqlNode.accept(new SqlShuttle() {
> @Override public SqlNode visit(SqlIdentifier identifier) {
> return new SqlIdentifier(identifier.names,
> identifier.getParserPosition());
> }
> });
> System.out.println(sqlNodeVisited.toString());
> }
> {code}
> !image-2020-05-25-17-38-36-009.png!
> Method threw 'java.lang.UnsupportedOperationException' exception. Cannot
> evaluate org.apache.calcite.sql.SqlBasicCall.toString()
> SqlInsert is a SqlSpecialOperator, when `toString` method is called, this
> problem is shown.We can see that `SqlSyntax#SPECIAL#unparse()` hasn't been
> implemented yet.
> exception :
> java.lang.UnsupportedOperationException: class
> org.apache.calcite.sql.SqlSyntax$6: SPECIAL
> at org.apache.calcite.util.Util.needToImplement(Util.java:967)
> at org.apache.calcite.sql.SqlSyntax$6.unparse(SqlSyntax.java:116)
> at org.apache.calcite.sql.SqlOperator.unparse(SqlOperator.java:333)
> at org.apache.calcite.sql.SqlDialect.unparseCall(SqlDialect.java:462)
> at org.apache.calcite.sql.SqlCall.unparse(SqlCall.java:104)
> at org.apache.calcite.sql.SqlNode.toSqlString(SqlNode.java:151)
> at org.apache.calcite.sql.SqlNode.toString(SqlNode.java:126)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4071) Make RelNode Immutable
[
https://issues.apache.org/jira/browse/CALCITE-4071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17147333#comment-17147333
]
Wang Yanlin commented on CALCITE-4071:
--
I would suggest deprecate it first, actually, in company project I'm working
on, we use replaceInput to do some change for RelNode.
> Make RelNode Immutable
> --
>
> Key: CALCITE-4071
> URL: https://issues.apache.org/jira/browse/CALCITE-4071
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Haisheng Yuan
>Priority: Major
>
> Currently, RelNode is mutable, mainly in planner. That makes planner code
> error-prone, hard to maintain, and complicate the logic. Let's try to avoid
> using {{replaceInput}}, at least inside planner, and see if we can deprecate
> {{replaceInput}}. That will make planner more robust.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CALCITE-4062) When deserialize UDF array type from json string, throw an exception
[
https://issues.apache.org/jira/browse/CALCITE-4062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin resolved CALCITE-4062.
--
Resolution: Fixed
Fixed in
[https://github.com/apache/calcite/commit/d8e559093f22ee5eefdee5758296efe3683d765b],
thanks [~xzh_dz]
> When deserialize UDF array type from json string, throw an exception
>
>
> Key: CALCITE-4062
> URL: https://issues.apache.org/jira/browse/CALCITE-4062
> Project: Calcite
> Issue Type: Wish
>Reporter: xzh_dz
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Function serialization and deserialization are often involved. When I run
> some tests, I find that some functions have exceptions during deserialization.
> The exception can be reproduced as below:
> RelWriterTest:
> {code:java}
> @Test void test() {
> final FrameworkConfig config = RelBuilderTest.config().build();
> final RelBuilder builder = RelBuilder.create(config);
> final RelNode rel = builder
> .scan("EMP")
> .project(
> builder.call(new MockSqlOperatorTable.SplitFunction(),
> builder.field("ENAME"), builder.literal(",")))
> .build();
> String relJson = RelOptUtil.dumpPlan("", rel,
> SqlExplainFormat.JSON, SqlExplainLevel.EXPPLAN_ATTRIBUTES);
> String s = deserializeAndDumpToTextFormat(getSchema(rel), relJson);
> System.out.println(s);
> }
> MockSqlOperatorTable:
> public static class SplitFunction extends SqlFunction {
> public SplitFunction() {
> super("split", new SqlIdentifier("split", SqlParserPos.ZERO),
> SqlKind.OTHER_FUNCTION, null,
> null, OperandTypes.family(SqlTypeFamily.STRING,
> SqlTypeFamily.STRING), null,
> SqlFunctionCategory.USER_DEFINED_FUNCTION);
> }
> @Override public RelDataType inferReturnType(SqlOperatorBinding
> opBinding) {
> final RelDataTypeFactory typeFactory =
> opBinding.getTypeFactory();
> return
> typeFactory.createArrayType(typeFactory.createSqlType(SqlTypeName.VARCHAR),
> -1);
> }
> }
> {code}
> Exception：
> {code:java}
> java.lang.RuntimeException: java.lang.RuntimeException:
> java.lang.AssertionError: use createArrayType() instead
> 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:838)
> at
> org.apache.calcite.plan.RelWriterTest.testArrayType(RelWriterTest.java:811)
> 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.en
[jira] [Comment Edited] (CALCITE-4019) Visit SqlInsert with SqlShuttle cause NullPointerException
[
https://issues.apache.org/jira/browse/CALCITE-4019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17120685#comment-17120685
]
Wang Yanlin edited comment on CALCITE-4019 at 6/1/20, 1:34 AM:
---
Sorry about that, my bad.
Should I reopen this jira and make another PR to fix it or should I create
another jira?
was (Author: yanlin-lynn):
Sorry about that, my bad.
How about I reopen this jira and make another PR to fix it?
> Visit SqlInsert with SqlShuttle cause NullPointerException
> --
>
> Key: CALCITE-4019
> URL: https://issues.apache.org/jira/browse/CALCITE-4019
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Priority: Major
> Fix For: 1.24.0
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> When visit a SqlInsert with SqlShuttle, got NPE, the stack trace is
> {noformat}
> java.lang.NullPointerException
> at com.google.common.collect.Iterators$8.transform(Iterators.java:817)
> at
> com.google.common.collect.TransformedIterator.next(TransformedIterator.java:48)
> at org.apache.calcite.sql.parser.SqlParserPos.sum(SqlParserPos.java:274)
> at
> org.apache.calcite.sql.parser.SqlParserPos.plusAll(SqlParserPos.java:183)
> at org.apache.calcite.sql.SqlOperator.createCall(SqlOperator.java:251)
> at
> org.apache.calcite.sql.util.SqlShuttle$CallCopyingArgHandler.result(SqlShuttle.java:117)
> at
> org.apache.calcite.sql.util.SqlShuttle$CallCopyingArgHandler.result(SqlShuttle.java:101)
> at org.apache.calcite.sql.util.SqlShuttle.visit(SqlShuttle.java:67)
> at org.apache.calcite.sql.util.SqlShuttle.visit(SqlShuttle.java:39)
> at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:139)
> at
> org.apache.calcite.sql.parser.SqlParserTest.testSqlParserPosPlus(SqlParserTest.java:8791)
> {noformat}
> Add this case in SqlParserTest to reproduce.
> return a new same SqlIdentifier for each SqlIdentifier, make sure
> [update|https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/util/SqlShuttle.java#L117]
>
> happends
> {noformat}
> @Test void testSqlParserPosPlus() throws Exception {
> final String sql = "insert into emps select * from emps";
> SqlNode sqlNode = getSqlParser(sql).parseStmt();
> sqlNode.accept(new SqlShuttle(){
> @Override
> public SqlNode visit(SqlIdentifier identifier) {
> return new SqlIdentifier(identifier.names,
> identifier.getParserPosition());
> }
> });
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4019) Visit SqlInsert with SqlShuttle cause NullPointerException
[
https://issues.apache.org/jira/browse/CALCITE-4019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17120685#comment-17120685
]
Wang Yanlin commented on CALCITE-4019:
--
Sorry about that, my bad.
How about I reopen this jira and make another PR to fix it?
> Visit SqlInsert with SqlShuttle cause NullPointerException
> --
>
> Key: CALCITE-4019
> URL: https://issues.apache.org/jira/browse/CALCITE-4019
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Priority: Major
> Fix For: 1.24.0
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> When visit a SqlInsert with SqlShuttle, got NPE, the stack trace is
> {noformat}
> java.lang.NullPointerException
> at com.google.common.collect.Iterators$8.transform(Iterators.java:817)
> at
> com.google.common.collect.TransformedIterator.next(TransformedIterator.java:48)
> at org.apache.calcite.sql.parser.SqlParserPos.sum(SqlParserPos.java:274)
> at
> org.apache.calcite.sql.parser.SqlParserPos.plusAll(SqlParserPos.java:183)
> at org.apache.calcite.sql.SqlOperator.createCall(SqlOperator.java:251)
> at
> org.apache.calcite.sql.util.SqlShuttle$CallCopyingArgHandler.result(SqlShuttle.java:117)
> at
> org.apache.calcite.sql.util.SqlShuttle$CallCopyingArgHandler.result(SqlShuttle.java:101)
> at org.apache.calcite.sql.util.SqlShuttle.visit(SqlShuttle.java:67)
> at org.apache.calcite.sql.util.SqlShuttle.visit(SqlShuttle.java:39)
> at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:139)
> at
> org.apache.calcite.sql.parser.SqlParserTest.testSqlParserPosPlus(SqlParserTest.java:8791)
> {noformat}
> Add this case in SqlParserTest to reproduce.
> return a new same SqlIdentifier for each SqlIdentifier, make sure
> [update|https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/util/SqlShuttle.java#L117]
>
> happends
> {noformat}
> @Test void testSqlParserPosPlus() throws Exception {
> final String sql = "insert into emps select * from emps";
> SqlNode sqlNode = getSqlParser(sql).parseStmt();
> sqlNode.accept(new SqlShuttle(){
> @Override
> public SqlNode visit(SqlIdentifier identifier) {
> return new SqlIdentifier(identifier.names,
> identifier.getParserPosition());
> }
> });
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4019) Visit SqlInsert with SqlShuttle cause NullPointerException
[
https://issues.apache.org/jira/browse/CALCITE-4019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin updated CALCITE-4019:
-
Fix Version/s: 1.24.0
> Visit SqlInsert with SqlShuttle cause NullPointerException
> --
>
> Key: CALCITE-4019
> URL: https://issues.apache.org/jira/browse/CALCITE-4019
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Priority: Major
> Fix For: 1.24.0
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> When visit a SqlInsert with SqlShuttle, got NPE, the stack trace is
> {noformat}
> java.lang.NullPointerException
> at com.google.common.collect.Iterators$8.transform(Iterators.java:817)
> at
> com.google.common.collect.TransformedIterator.next(TransformedIterator.java:48)
> at org.apache.calcite.sql.parser.SqlParserPos.sum(SqlParserPos.java:274)
> at
> org.apache.calcite.sql.parser.SqlParserPos.plusAll(SqlParserPos.java:183)
> at org.apache.calcite.sql.SqlOperator.createCall(SqlOperator.java:251)
> at
> org.apache.calcite.sql.util.SqlShuttle$CallCopyingArgHandler.result(SqlShuttle.java:117)
> at
> org.apache.calcite.sql.util.SqlShuttle$CallCopyingArgHandler.result(SqlShuttle.java:101)
> at org.apache.calcite.sql.util.SqlShuttle.visit(SqlShuttle.java:67)
> at org.apache.calcite.sql.util.SqlShuttle.visit(SqlShuttle.java:39)
> at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:139)
> at
> org.apache.calcite.sql.parser.SqlParserTest.testSqlParserPosPlus(SqlParserTest.java:8791)
> {noformat}
> Add this case in SqlParserTest to reproduce.
> return a new same SqlIdentifier for each SqlIdentifier, make sure
> [update|https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/util/SqlShuttle.java#L117]
>
> happends
> {noformat}
> @Test void testSqlParserPosPlus() throws Exception {
> final String sql = "insert into emps select * from emps";
> SqlNode sqlNode = getSqlParser(sql).parseStmt();
> sqlNode.accept(new SqlShuttle(){
> @Override
> public SqlNode visit(SqlIdentifier identifier) {
> return new SqlIdentifier(identifier.names,
> identifier.getParserPosition());
> }
> });
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4019) Visit SqlInsert with SqlShuttle cause NullPointerException
[
https://issues.apache.org/jira/browse/CALCITE-4019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17119199#comment-17119199
]
Wang Yanlin commented on CALCITE-4019:
--
fixed in
[https://github.com/apache/calcite/commit/abe772018a6adb5007429e0c1c83b6e7d83a1c71],
thanks [~xzh_dz]
> Visit SqlInsert with SqlShuttle cause NullPointerException
> --
>
> Key: CALCITE-4019
> URL: https://issues.apache.org/jira/browse/CALCITE-4019
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Priority: Major
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> When visit a SqlInsert with SqlShuttle, got NPE, the stack trace is
> {noformat}
> java.lang.NullPointerException
> at com.google.common.collect.Iterators$8.transform(Iterators.java:817)
> at
> com.google.common.collect.TransformedIterator.next(TransformedIterator.java:48)
> at org.apache.calcite.sql.parser.SqlParserPos.sum(SqlParserPos.java:274)
> at
> org.apache.calcite.sql.parser.SqlParserPos.plusAll(SqlParserPos.java:183)
> at org.apache.calcite.sql.SqlOperator.createCall(SqlOperator.java:251)
> at
> org.apache.calcite.sql.util.SqlShuttle$CallCopyingArgHandler.result(SqlShuttle.java:117)
> at
> org.apache.calcite.sql.util.SqlShuttle$CallCopyingArgHandler.result(SqlShuttle.java:101)
> at org.apache.calcite.sql.util.SqlShuttle.visit(SqlShuttle.java:67)
> at org.apache.calcite.sql.util.SqlShuttle.visit(SqlShuttle.java:39)
> at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:139)
> at
> org.apache.calcite.sql.parser.SqlParserTest.testSqlParserPosPlus(SqlParserTest.java:8791)
> {noformat}
> Add this case in SqlParserTest to reproduce.
> return a new same SqlIdentifier for each SqlIdentifier, make sure
> [update|https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/util/SqlShuttle.java#L117]
>
> happends
> {noformat}
> @Test void testSqlParserPosPlus() throws Exception {
> final String sql = "insert into emps select * from emps";
> SqlNode sqlNode = getSqlParser(sql).parseStmt();
> sqlNode.accept(new SqlShuttle(){
> @Override
> public SqlNode visit(SqlIdentifier identifier) {
> return new SqlIdentifier(identifier.names,
> identifier.getParserPosition());
> }
> });
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CALCITE-4019) Visit SqlInsert with SqlShuttle cause NullPointerException
[
https://issues.apache.org/jira/browse/CALCITE-4019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin resolved CALCITE-4019.
--
Resolution: Fixed
> Visit SqlInsert with SqlShuttle cause NullPointerException
> --
>
> Key: CALCITE-4019
> URL: https://issues.apache.org/jira/browse/CALCITE-4019
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Priority: Major
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> When visit a SqlInsert with SqlShuttle, got NPE, the stack trace is
> {noformat}
> java.lang.NullPointerException
> at com.google.common.collect.Iterators$8.transform(Iterators.java:817)
> at
> com.google.common.collect.TransformedIterator.next(TransformedIterator.java:48)
> at org.apache.calcite.sql.parser.SqlParserPos.sum(SqlParserPos.java:274)
> at
> org.apache.calcite.sql.parser.SqlParserPos.plusAll(SqlParserPos.java:183)
> at org.apache.calcite.sql.SqlOperator.createCall(SqlOperator.java:251)
> at
> org.apache.calcite.sql.util.SqlShuttle$CallCopyingArgHandler.result(SqlShuttle.java:117)
> at
> org.apache.calcite.sql.util.SqlShuttle$CallCopyingArgHandler.result(SqlShuttle.java:101)
> at org.apache.calcite.sql.util.SqlShuttle.visit(SqlShuttle.java:67)
> at org.apache.calcite.sql.util.SqlShuttle.visit(SqlShuttle.java:39)
> at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:139)
> at
> org.apache.calcite.sql.parser.SqlParserTest.testSqlParserPosPlus(SqlParserTest.java:8791)
> {noformat}
> Add this case in SqlParserTest to reproduce.
> return a new same SqlIdentifier for each SqlIdentifier, make sure
> [update|https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/util/SqlShuttle.java#L117]
>
> happends
> {noformat}
> @Test void testSqlParserPosPlus() throws Exception {
> final String sql = "insert into emps select * from emps";
> SqlNode sqlNode = getSqlParser(sql).parseStmt();
> sqlNode.accept(new SqlShuttle(){
> @Override
> public SqlNode visit(SqlIdentifier identifier) {
> return new SqlIdentifier(identifier.names,
> identifier.getParserPosition());
> }
> });
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3919) Upgrade ProjectJoinTransposeRule to allow user choose whether to keep join condition
[
https://issues.apache.org/jira/browse/CALCITE-3919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114574#comment-17114574
]
Wang Yanlin commented on CALCITE-3919:
--
I'll just close this Jira since there exists some objections.
> Upgrade ProjectJoinTransposeRule to allow user choose whether to keep join
> condition
>
>
> Key: CALCITE-3919
> URL: https://issues.apache.org/jira/browse/CALCITE-3919
> Project: Calcite
> Issue Type: Improvement
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently, when apply ProjectJoinTransposeRule, the join condition may be
> also pushed, for example
> for sql
> {noformat}
> select emp.ename, sum(bonus.sal) from emp left outer join bonus on emp.ename
> = bonus.ename and floor(emp.sal) > 10 group by emp.ename
> {noformat}
> the algebra is
> {noformat}
> LogicalAggregate(group=[{0}], EXPR$1=[SUM($1)])
> LogicalProject(ENAME=[$1], SAL0=[$11])
> LogicalJoin(condition=[AND(=($1, $9), >(FLOOR($5), 10))], joinType=[left])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalTableScan(table=[[CATALOG, SALES, BONUS]])
> {noformat}
> After applying *ProjectJoinTransposeRule*, the join condition 'floor(emp.sal)
> > 10' is also pushed down,
> {noformat}
> LogicalAggregate(group=[{0}], EXPR$1=[SUM($1)])
> LogicalProject(ENAME=[$0], SAL0=[$3])
> LogicalJoin(condition=[AND(=($0, $2), $1)], joinType=[left])
> LogicalProject(ENAME=[$1], >=[>(FLOOR($5), 10)])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalProject(ENAME=[$0], SAL=[$2])
> LogicalTableScan(table=[[CATALOG, SALES, BONUS]])
> {noformat}
> In some cases, users may want to push Project past Join, but keep the join
> condition unchanged, so we can upgrade *ProjectJoinTransposeRule* to allow
> user choose whether to keep join condition
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (CALCITE-3919) Upgrade ProjectJoinTransposeRule to allow user choose whether to keep join condition
[
https://issues.apache.org/jira/browse/CALCITE-3919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin closed CALCITE-3919.
Resolution: Not A Problem
> Upgrade ProjectJoinTransposeRule to allow user choose whether to keep join
> condition
>
>
> Key: CALCITE-3919
> URL: https://issues.apache.org/jira/browse/CALCITE-3919
> Project: Calcite
> Issue Type: Improvement
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently, when apply ProjectJoinTransposeRule, the join condition may be
> also pushed, for example
> for sql
> {noformat}
> select emp.ename, sum(bonus.sal) from emp left outer join bonus on emp.ename
> = bonus.ename and floor(emp.sal) > 10 group by emp.ename
> {noformat}
> the algebra is
> {noformat}
> LogicalAggregate(group=[{0}], EXPR$1=[SUM($1)])
> LogicalProject(ENAME=[$1], SAL0=[$11])
> LogicalJoin(condition=[AND(=($1, $9), >(FLOOR($5), 10))], joinType=[left])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalTableScan(table=[[CATALOG, SALES, BONUS]])
> {noformat}
> After applying *ProjectJoinTransposeRule*, the join condition 'floor(emp.sal)
> > 10' is also pushed down,
> {noformat}
> LogicalAggregate(group=[{0}], EXPR$1=[SUM($1)])
> LogicalProject(ENAME=[$0], SAL0=[$3])
> LogicalJoin(condition=[AND(=($0, $2), $1)], joinType=[left])
> LogicalProject(ENAME=[$1], >=[>(FLOOR($5), 10)])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalProject(ENAME=[$0], SAL=[$2])
> LogicalTableScan(table=[[CATALOG, SALES, BONUS]])
> {noformat}
> In some cases, users may want to push Project past Join, but keep the join
> condition unchanged, so we can upgrade *ProjectJoinTransposeRule* to allow
> user choose whether to keep join condition
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4019) Visit SqlInsert with SqlShuttle cause NullPointerException
[
https://issues.apache.org/jira/browse/CALCITE-4019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114570#comment-17114570
]
Wang Yanlin commented on CALCITE-4019:
--
Thanks [~xzh_dz] for following this jira, feel free to work on this.
> Visit SqlInsert with SqlShuttle cause NullPointerException
> --
>
> Key: CALCITE-4019
> URL: https://issues.apache.org/jira/browse/CALCITE-4019
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Priority: Major
>
> When visit a SqlInsert with SqlShuttle, got NPE, the stack trace is
> {noformat}
> java.lang.NullPointerException
> at com.google.common.collect.Iterators$8.transform(Iterators.java:817)
> at
> com.google.common.collect.TransformedIterator.next(TransformedIterator.java:48)
> at org.apache.calcite.sql.parser.SqlParserPos.sum(SqlParserPos.java:274)
> at
> org.apache.calcite.sql.parser.SqlParserPos.plusAll(SqlParserPos.java:183)
> at org.apache.calcite.sql.SqlOperator.createCall(SqlOperator.java:251)
> at
> org.apache.calcite.sql.util.SqlShuttle$CallCopyingArgHandler.result(SqlShuttle.java:117)
> at
> org.apache.calcite.sql.util.SqlShuttle$CallCopyingArgHandler.result(SqlShuttle.java:101)
> at org.apache.calcite.sql.util.SqlShuttle.visit(SqlShuttle.java:67)
> at org.apache.calcite.sql.util.SqlShuttle.visit(SqlShuttle.java:39)
> at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:139)
> at
> org.apache.calcite.sql.parser.SqlParserTest.testSqlParserPosPlus(SqlParserTest.java:8791)
> {noformat}
> Add this case in SqlParserTest to reproduce.
> return a new same SqlIdentifier for each SqlIdentifier, make sure
> [update|https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/util/SqlShuttle.java#L117]
>
> happends
> {noformat}
> @Test void testSqlParserPosPlus() throws Exception {
> final String sql = "insert into emps select * from emps";
> SqlNode sqlNode = getSqlParser(sql).parseStmt();
> sqlNode.accept(new SqlShuttle(){
> @Override
> public SqlNode visit(SqlIdentifier identifier) {
> return new SqlIdentifier(identifier.names,
> identifier.getParserPosition());
> }
> });
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4019) Visit SqlInsert with SqlShuttle cause NullPointerException
[
https://issues.apache.org/jira/browse/CALCITE-4019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin updated CALCITE-4019:
-
Description:
When visit a SqlInsert with SqlShuttle, got NPE, the stack trace is
{noformat}
java.lang.NullPointerException
at com.google.common.collect.Iterators$8.transform(Iterators.java:817)
at
com.google.common.collect.TransformedIterator.next(TransformedIterator.java:48)
at org.apache.calcite.sql.parser.SqlParserPos.sum(SqlParserPos.java:274)
at
org.apache.calcite.sql.parser.SqlParserPos.plusAll(SqlParserPos.java:183)
at org.apache.calcite.sql.SqlOperator.createCall(SqlOperator.java:251)
at
org.apache.calcite.sql.util.SqlShuttle$CallCopyingArgHandler.result(SqlShuttle.java:117)
at
org.apache.calcite.sql.util.SqlShuttle$CallCopyingArgHandler.result(SqlShuttle.java:101)
at org.apache.calcite.sql.util.SqlShuttle.visit(SqlShuttle.java:67)
at org.apache.calcite.sql.util.SqlShuttle.visit(SqlShuttle.java:39)
at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:139)
at
org.apache.calcite.sql.parser.SqlParserTest.testSqlParserPosPlus(SqlParserTest.java:8791)
{noformat}
Add this case in SqlParserTest to reproduce.
return a new same SqlIdentifier for each SqlIdentifier, make sure
[update|https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/util/SqlShuttle.java#L117]
happends
{noformat}
@Test void testSqlParserPosPlus() throws Exception {
final String sql = "insert into emps select * from emps";
SqlNode sqlNode = getSqlParser(sql).parseStmt();
sqlNode.accept(new SqlShuttle(){
@Override
public SqlNode visit(SqlIdentifier identifier) {
return new SqlIdentifier(identifier.names,
identifier.getParserPosition());
}
});
}
{noformat}
was:
When visit a SqlInsert with SqlShuttle, got NPE, the stack trace is
{noformat}
java.lang.NullPointerException
at com.google.common.collect.Iterators$8.transform(Iterators.java:817)
at
com.google.common.collect.TransformedIterator.next(TransformedIterator.java:48)
at org.apache.calcite.sql.parser.SqlParserPos.sum(SqlParserPos.java:274)
at
org.apache.calcite.sql.parser.SqlParserPos.plusAll(SqlParserPos.java:183)
at
org.apache.calcite.sql.parser.SqlParserTest.testSqlParserPosPlus(SqlParserTest.java:8793)
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(TestMetho
[jira] [Commented] (CALCITE-4019) Visit SqlInsert with SqlShuttle cause NullPointerException
[
https://issues.apache.org/jira/browse/CALCITE-4019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17113672#comment-17113672
]
Wang Yanlin commented on CALCITE-4019:
--
[~julianhyde], thanks for following this jira, the former test case in
description is incorrect and misleading, sorry for that.
I update the test case in description. The NullPointerException occurs when
visit SqlInsert with SqlShuttle and some update happends.
> Visit SqlInsert with SqlShuttle cause NullPointerException
> --
>
> Key: CALCITE-4019
> URL: https://issues.apache.org/jira/browse/CALCITE-4019
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Priority: Major
>
> When visit a SqlInsert with SqlShuttle, got NPE, the stack trace is
> {noformat}
> java.lang.NullPointerException
> at com.google.common.collect.Iterators$8.transform(Iterators.java:817)
> at
> com.google.common.collect.TransformedIterator.next(TransformedIterator.java:48)
> at org.apache.calcite.sql.parser.SqlParserPos.sum(SqlParserPos.java:274)
> at
> org.apache.calcite.sql.parser.SqlParserPos.plusAll(SqlParserPos.java:183)
> at
> org.apache.calcite.sql.parser.SqlParserTest.testSqlParserPosPlus(SqlParserTest.java:8793)
> 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)
>
[jira] [Updated] (CALCITE-4019) Visit SqlInsert with SqlShuttle cause NullPointerException
[
https://issues.apache.org/jira/browse/CALCITE-4019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin updated CALCITE-4019:
-
Description:
When visit a SqlInsert with SqlShuttle, got NPE, the stack trace is
{noformat}
java.lang.NullPointerException
at com.google.common.collect.Iterators$8.transform(Iterators.java:817)
at
com.google.common.collect.TransformedIterator.next(TransformedIterator.java:48)
at org.apache.calcite.sql.parser.SqlParserPos.sum(SqlParserPos.java:274)
at
org.apache.calcite.sql.parser.SqlParserPos.plusAll(SqlParserPos.java:183)
at
org.apache.calcite.sql.parser.SqlParserTest.testSqlParserPosPlus(SqlParserTest.java:8793)
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
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)
[jira] [Updated] (CALCITE-4019) Visit SqlInsert with SqlShuttle cause NullPointerException
[
https://issues.apache.org/jira/browse/CALCITE-4019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin updated CALCITE-4019:
-
Description:
When visit a SqlInsert with SqlShuttle, got NPE, the stack trace is
{noformat}
java.lang.NullPointerException
at com.google.common.collect.Iterators$8.transform(Iterators.java:817)
at
com.google.common.collect.TransformedIterator.next(TransformedIterator.java:48)
at org.apache.calcite.sql.parser.SqlParserPos.sum(SqlParserPos.java:274)
at
org.apache.calcite.sql.parser.SqlParserPos.plusAll(SqlParserPos.java:183)
at
org.apache.calcite.sql.parser.SqlParserTest.testSqlParserPosPlus(SqlParserTest.java:8793)
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
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)
[jira] [Created] (CALCITE-4019) Visit SqlInsert with SqlShuttle cause NullPointerException
Wang Yanlin created CALCITE-4019:
Summary: Visit SqlInsert with SqlShuttle cause NullPointerException
Key: CALCITE-4019
URL: https://issues.apache.org/jira/browse/CALCITE-4019
Project: Calcite
Issue Type: Bug
Reporter: Wang Yanlin
When visit a SqlInsert with SqlShuttle, got NPE, the stack trace is
{noformat}
java.lang.NullPointerException
at com.google.common.collect.Iterators$8.transform(Iterators.java:817)
at
com.google.common.collect.TransformedIterator.next(TransformedIterator.java:48)
at org.apache.calcite.sql.parser.SqlParserPos.sum(SqlParserPos.java:274)
at
org.apache.calcite.sql.parser.SqlParserPos.plusAll(SqlParserPos.java:183)
at
org.apache.calcite.sql.parser.SqlParserTest.testSqlParserPosPlus(SqlParserTest.java:8793)
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
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$7(NodeTestTask.java:125)
at
org.junit.platform.engine.support.hierarchical.Node.around(Node.jav
[jira] [Commented] (CALCITE-4001) Should support dialect when unparsing SqlDataTypeSpec
[
https://issues.apache.org/jira/browse/CALCITE-4001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17107108#comment-17107108
]
Wang Yanlin commented on CALCITE-4001:
--
May be add
{noformat}
public void unparseType(SqlWriter writer, RelDataType dataType, int leftPrec,
int rightPrec)
{noformat}
in sql dialect.
> Should support dialect when unparsing SqlDataTypeSpec
> -
>
> Key: CALCITE-4001
> URL: https://issues.apache.org/jira/browse/CALCITE-4001
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Xurenhe
>Priority: Minor
>
> SqlBasicTypeNameSpec cannot cover all data types of other sql's engine, when
> doing SqlNode To SqlString,
> such as cast(id as bigint), but some sql-engine only support cast(id as long).
> I think there should be based on dialect, just like
> org.apache.calcite.sql.SqlDialect#unparseOffsetFetch.
--
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&focusedCommentId=17098292#comment-17098292
]
Wang Yanlin commented on CALCITE-3929:
--
[~wojustme] you can apply by yourself, see the documentation in
[https://calcite.apache.org/develop/]
> 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
[jira] [Commented] (CALCITE-3919) Upgrade ProjectJoinTransposeRule to allow user choose whether to keep join condition
[
https://issues.apache.org/jira/browse/CALCITE-3919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17097950#comment-17097950
]
Wang Yanlin commented on CALCITE-3919:
--
Hi, [~zabetak] , I came across a similar case when apply the
*FilterJoinRule.FILTER_ON_JOIN* rule. In this case I just want to keep filter
past down join and keep the join condition unchanged. But after applying the
rule, part of the join condition also pushed down.
What do you think of it, should I also forbid the push-down. If someone want
to push join condition down, he/she can use *FilterJoinRule.JOIN* to do it.
The sql of the case is
{code:java}
final String sql = "select e.deptno, e.ename, d.name\n"
+ "from emp as e\n"
+ "join dept as d\n"
+ "on e.deptno = d.deptno\n"
+ "and name = 'dbc'\n"
+ "where ename = 'abc'\n";
{code}
Before apply any rule, the relation algebra is
{noformat}
LogicalProject(DEPTNO=[$7], ENAME=[$1], NAME=[$10])
LogicalFilter(condition=[=($1, 'abc')])
LogicalJoin(condition=[AND(=($7, $9), =($10, 'dbc'))], joinType=[inner])
LogicalTableScan(table=[[CATALOG, SALES, EMP]])
LogicalTableScan(table=[[CATALOG, SALES, DEPT]])
{noformat}
after apply FilterJoinRule.FILTER_ON_JOIN, the returned algebra is
{noformat}
LogicalProject(DEPTNO=[$7], ENAME=[$1], NAME=[$10])
LogicalJoin(condition=[=($7, $9)], joinType=[inner])
LogicalFilter(condition=[=($1, 'abc')])
LogicalTableScan(table=[[CATALOG, SALES, EMP]])
LogicalFilter(condition=[=($1, 'dbc')])
LogicalTableScan(table=[[CATALOG, SALES, DEPT]])
{noformat}
as you can see, part of the join condition also pushed down.
> Upgrade ProjectJoinTransposeRule to allow user choose whether to keep join
> condition
>
>
> Key: CALCITE-3919
> URL: https://issues.apache.org/jira/browse/CALCITE-3919
> Project: Calcite
> Issue Type: Improvement
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently, when apply ProjectJoinTransposeRule, the join condition may be
> also pushed, for example
> for sql
> {noformat}
> select emp.ename, sum(bonus.sal) from emp left outer join bonus on emp.ename
> = bonus.ename and floor(emp.sal) > 10 group by emp.ename
> {noformat}
> the algebra is
> {noformat}
> LogicalAggregate(group=[{0}], EXPR$1=[SUM($1)])
> LogicalProject(ENAME=[$1], SAL0=[$11])
> LogicalJoin(condition=[AND(=($1, $9), >(FLOOR($5), 10))], joinType=[left])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalTableScan(table=[[CATALOG, SALES, BONUS]])
> {noformat}
> After applying *ProjectJoinTransposeRule*, the join condition 'floor(emp.sal)
> > 10' is also pushed down,
> {noformat}
> LogicalAggregate(group=[{0}], EXPR$1=[SUM($1)])
> LogicalProject(ENAME=[$0], SAL0=[$3])
> LogicalJoin(condition=[AND(=($0, $2), $1)], joinType=[left])
> LogicalProject(ENAME=[$1], >=[>(FLOOR($5), 10)])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalProject(ENAME=[$0], SAL=[$2])
> LogicalTableScan(table=[[CATALOG, SALES, BONUS]])
> {noformat}
> In some cases, users may want to push Project past Join, but keep the join
> condition unchanged, so we can upgrade *ProjectJoinTransposeRule* to allow
> user choose whether to keep join condition
--
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&focusedCommentId=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
> org.
[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
> org.junit.platform.engine.support.hierarchical.SameThreadHierarchicalTestE
[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
org.junit.platform.engine.support.hi
[jira] [Assigned] (CALCITE-3921) Support serialize TableModify to json string and deserialize from it
[
https://issues.apache.org/jira/browse/CALCITE-3921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin reassigned CALCITE-3921:
Assignee: Wang Yanlin
> Support serialize TableModify to json string and deserialize from it
>
>
> Key: CALCITE-3921
> URL: https://issues.apache.org/jira/browse/CALCITE-3921
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Major
>
> When trying to serialize TableModify to json string, got
> {noformat}
> java.lang.UnsupportedOperationException: type not serializable: INSERT (type
> org.apache.calcite.rel.core.TableModify.Operation)
> at org.apache.calcite.rel.externalize.RelJson.toJson(RelJson.java:322)
> at
> org.apache.calcite.rel.externalize.RelJsonWriter.put(RelJsonWriter.java:84)
> at
> org.apache.calcite.rel.externalize.RelJsonWriter.explain_(RelJsonWriter.java:67)
> at
> org.apache.calcite.rel.externalize.RelJsonWriter.done(RelJsonWriter.java:129)
> at
> org.apache.calcite.rel.AbstractRelNode.explain(AbstractRelNode.java:303)
> at org.apache.calcite.plan.RelOptUtil.dumpPlan(RelOptUtil.java:2110)
> at
> org.apache.calcite.plan.RelWriterTest.testTableModify(RelWriterTest.java:922)
> 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(Arr
[jira] [Created] (CALCITE-3921) Support serialize TableModify to json string and deserialize from it
Wang Yanlin created CALCITE-3921:
Summary: Support serialize TableModify to json string and
deserialize from it
Key: CALCITE-3921
URL: https://issues.apache.org/jira/browse/CALCITE-3921
Project: Calcite
Issue Type: Bug
Reporter: Wang Yanlin
When trying to serialize TableModify to json string, got
{noformat}
java.lang.UnsupportedOperationException: type not serializable: INSERT (type
org.apache.calcite.rel.core.TableModify.Operation)
at org.apache.calcite.rel.externalize.RelJson.toJson(RelJson.java:322)
at
org.apache.calcite.rel.externalize.RelJsonWriter.put(RelJsonWriter.java:84)
at
org.apache.calcite.rel.externalize.RelJsonWriter.explain_(RelJsonWriter.java:67)
at
org.apache.calcite.rel.externalize.RelJsonWriter.done(RelJsonWriter.java:129)
at
org.apache.calcite.rel.AbstractRelNode.explain(AbstractRelNode.java:303)
at org.apache.calcite.plan.RelOptUtil.dumpPlan(RelOptUtil.java:2110)
at
org.apache.calcite.plan.RelWriterTest.testTableModify(RelWriterTest.java:922)
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.hierarc
[jira] [Commented] (CALCITE-3919) Upgrade ProjectJoinTransposeRule to allow user choose whether to keep join condition
[
https://issues.apache.org/jira/browse/CALCITE-3919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17082795#comment-17082795
]
Wang Yanlin commented on CALCITE-3919:
--
Hi, [~Chunwei Lei] , I'm currently working on a project which depends on
calcite. In this project, I need to recognize some special pattern in the
condition of join, and do some rewrite according to it. This is not a common
sense semantics-equal rewrite. While I need to push project past join, but to
keep the pattern in join condition.
BTW, I'm OK to just forbid this kind of join condition push-down, it makes
things simple.
> Upgrade ProjectJoinTransposeRule to allow user choose whether to keep join
> condition
>
>
> Key: CALCITE-3919
> URL: https://issues.apache.org/jira/browse/CALCITE-3919
> Project: Calcite
> Issue Type: Improvement
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently, when apply ProjectJoinTransposeRule, the join condition may be
> also pushed, for example
> for sql
> {noformat}
> select emp.ename, sum(bonus.sal) from emp left outer join bonus on emp.ename
> = bonus.ename and floor(emp.sal) > 10 group by emp.ename
> {noformat}
> the algebra is
> {noformat}
> LogicalAggregate(group=[{0}], EXPR$1=[SUM($1)])
> LogicalProject(ENAME=[$1], SAL0=[$11])
> LogicalJoin(condition=[AND(=($1, $9), >(FLOOR($5), 10))], joinType=[left])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalTableScan(table=[[CATALOG, SALES, BONUS]])
> {noformat}
> After applying *ProjectJoinTransposeRule*, the join condition 'floor(emp.sal)
> > 10' is also pushed down,
> {noformat}
> LogicalAggregate(group=[{0}], EXPR$1=[SUM($1)])
> LogicalProject(ENAME=[$0], SAL0=[$3])
> LogicalJoin(condition=[AND(=($0, $2), $1)], joinType=[left])
> LogicalProject(ENAME=[$1], >=[>(FLOOR($5), 10)])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalProject(ENAME=[$0], SAL=[$2])
> LogicalTableScan(table=[[CATALOG, SALES, BONUS]])
> {noformat}
> In some cases, users may want to push Project past Join, but keep the join
> condition unchanged, so we can upgrade *ProjectJoinTransposeRule* to allow
> user choose whether to keep join condition
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (CALCITE-3919) Upgrade ProjectJoinTransposeRule to allow user choose whether to keep join condition
[
https://issues.apache.org/jira/browse/CALCITE-3919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin reassigned CALCITE-3919:
Assignee: Wang Yanlin
> Upgrade ProjectJoinTransposeRule to allow user choose whether to keep join
> condition
>
>
> Key: CALCITE-3919
> URL: https://issues.apache.org/jira/browse/CALCITE-3919
> Project: Calcite
> Issue Type: Improvement
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently, when apply ProjectJoinTransposeRule, the join condition may be
> also pushed, for example
> for sql
> {noformat}
> select emp.ename, sum(bonus.sal) from emp left outer join bonus on emp.ename
> = bonus.ename and floor(emp.sal) > 10 group by emp.ename
> {noformat}
> the algebra is
> {noformat}
> LogicalAggregate(group=[{0}], EXPR$1=[SUM($1)])
> LogicalProject(ENAME=[$1], SAL0=[$11])
> LogicalJoin(condition=[AND(=($1, $9), >(FLOOR($5), 10))], joinType=[left])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalTableScan(table=[[CATALOG, SALES, BONUS]])
> {noformat}
> After applying *ProjectJoinTransposeRule*, the join condition 'floor(emp.sal)
> > 10' is also pushed down,
> {noformat}
> LogicalAggregate(group=[{0}], EXPR$1=[SUM($1)])
> LogicalProject(ENAME=[$0], SAL0=[$3])
> LogicalJoin(condition=[AND(=($0, $2), $1)], joinType=[left])
> LogicalProject(ENAME=[$1], >=[>(FLOOR($5), 10)])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalProject(ENAME=[$0], SAL=[$2])
> LogicalTableScan(table=[[CATALOG, SALES, BONUS]])
> {noformat}
> In some cases, users may want to push Project past Join, but keep the join
> condition unchanged, so we can upgrade *ProjectJoinTransposeRule* to allow
> user choose whether to keep join condition
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3919) Upgrade ProjectJoinTransposeRule to allow user choose whether to keep join condition
[
https://issues.apache.org/jira/browse/CALCITE-3919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin updated CALCITE-3919:
-
Description:
Currently, when apply ProjectJoinTransposeRule, the join condition may be also
pushed, for example
for sql
{noformat}
select emp.ename, sum(bonus.sal) from emp left outer join bonus on emp.ename =
bonus.ename and floor(emp.sal) > 10 group by emp.ename
{noformat}
the algebra is
{noformat}
LogicalAggregate(group=[{0}], EXPR$1=[SUM($1)])
LogicalProject(ENAME=[$1], SAL0=[$11])
LogicalJoin(condition=[AND(=($1, $9), >(FLOOR($5), 10))], joinType=[left])
LogicalTableScan(table=[[CATALOG, SALES, EMP]])
LogicalTableScan(table=[[CATALOG, SALES, BONUS]])
{noformat}
After applying *ProjectJoinTransposeRule*, the join condition 'floor(emp.sal) >
10' is also pushed down,
{noformat}
LogicalAggregate(group=[{0}], EXPR$1=[SUM($1)])
LogicalProject(ENAME=[$0], SAL0=[$3])
LogicalJoin(condition=[AND(=($0, $2), $1)], joinType=[left])
LogicalProject(ENAME=[$1], >=[>(FLOOR($5), 10)])
LogicalTableScan(table=[[CATALOG, SALES, EMP]])
LogicalProject(ENAME=[$0], SAL=[$2])
LogicalTableScan(table=[[CATALOG, SALES, BONUS]])
{noformat}
In some cases, users may want to push Project past Join, but keep the join
condition unchanged, so we can upgrade *ProjectJoinTransposeRule* to allow user
choose whether to keep join condition
was:
Currently, when apply ProjectJoinTransposeRule, the join condition may be also
pushed, for example
for sql
The relation algebra
for sql
{noformat}
select emp.ename, sum(bonus.sal) from emp left outer join bonus on emp.ename =
bonus.ename and floor(emp.sal) > 10 group by emp.ename
{noformat}
is
{noformat}
LogicalAggregate(group=[{0}], EXPR$1=[SUM($1)])
LogicalProject(ENAME=[$1], SAL0=[$11])
LogicalJoin(condition=[AND(=($1, $9), >(FLOOR($5), 10))], joinType=[left])
LogicalTableScan(table=[[CATALOG, SALES, EMP]])
LogicalTableScan(table=[[CATALOG, SALES, BONUS]])
{noformat}
After applying *ProjectJoinTransposeRule*, the join condition 'floor(emp.sal) >
10' is also pushed down,
{noformat}
LogicalAggregate(group=[{0}], EXPR$1=[SUM($1)])
LogicalProject(ENAME=[$0], SAL0=[$3])
LogicalJoin(condition=[AND(=($0, $2), $1)], joinType=[left])
LogicalProject(ENAME=[$1], >=[>(FLOOR($5), 10)])
LogicalTableScan(table=[[CATALOG, SALES, EMP]])
LogicalProject(ENAME=[$0], SAL=[$2])
LogicalTableScan(table=[[CATALOG, SALES, BONUS]])
{noformat}
In some cases, users may want to push Project past Join, but keep the join
condition unchanged, so we can upgrade *ProjectJoinTransposeRule* to allow user
choose whether to keep join condition
> Upgrade ProjectJoinTransposeRule to allow user choose whether to keep join
> condition
>
>
> Key: CALCITE-3919
> URL: https://issues.apache.org/jira/browse/CALCITE-3919
> Project: Calcite
> Issue Type: Improvement
>Reporter: Wang Yanlin
>Priority: Major
>
> Currently, when apply ProjectJoinTransposeRule, the join condition may be
> also pushed, for example
> for sql
> {noformat}
> select emp.ename, sum(bonus.sal) from emp left outer join bonus on emp.ename
> = bonus.ename and floor(emp.sal) > 10 group by emp.ename
> {noformat}
> the algebra is
> {noformat}
> LogicalAggregate(group=[{0}], EXPR$1=[SUM($1)])
> LogicalProject(ENAME=[$1], SAL0=[$11])
> LogicalJoin(condition=[AND(=($1, $9), >(FLOOR($5), 10))], joinType=[left])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalTableScan(table=[[CATALOG, SALES, BONUS]])
> {noformat}
> After applying *ProjectJoinTransposeRule*, the join condition 'floor(emp.sal)
> > 10' is also pushed down,
> {noformat}
> LogicalAggregate(group=[{0}], EXPR$1=[SUM($1)])
> LogicalProject(ENAME=[$0], SAL0=[$3])
> LogicalJoin(condition=[AND(=($0, $2), $1)], joinType=[left])
> LogicalProject(ENAME=[$1], >=[>(FLOOR($5), 10)])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalProject(ENAME=[$0], SAL=[$2])
> LogicalTableScan(table=[[CATALOG, SALES, BONUS]])
> {noformat}
> In some cases, users may want to push Project past Join, but keep the join
> condition unchanged, so we can upgrade *ProjectJoinTransposeRule* to allow
> user choose whether to keep join condition
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3919) Upgrade ProjectJoinTransposeRule to allow user choose whether to keep join condition
[
https://issues.apache.org/jira/browse/CALCITE-3919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin updated CALCITE-3919:
-
Description:
Currently, when apply ProjectJoinTransposeRule, the join condition may be also
pushed, for example
for sql
The relation algebra
for sql
{noformat}
select emp.ename, sum(bonus.sal) from emp left outer join bonus on emp.ename =
bonus.ename and floor(emp.sal) > 10 group by emp.ename
{noformat}
is
{noformat}
LogicalAggregate(group=[{0}], EXPR$1=[SUM($1)])
LogicalProject(ENAME=[$1], SAL0=[$11])
LogicalJoin(condition=[AND(=($1, $9), >(FLOOR($5), 10))], joinType=[left])
LogicalTableScan(table=[[CATALOG, SALES, EMP]])
LogicalTableScan(table=[[CATALOG, SALES, BONUS]])
{noformat}
After applying *ProjectJoinTransposeRule*, the join condition 'floor(emp.sal) >
10' is also pushed down,
{noformat}
LogicalAggregate(group=[{0}], EXPR$1=[SUM($1)])
LogicalProject(ENAME=[$0], SAL0=[$3])
LogicalJoin(condition=[AND(=($0, $2), $1)], joinType=[left])
LogicalProject(ENAME=[$1], >=[>(FLOOR($5), 10)])
LogicalTableScan(table=[[CATALOG, SALES, EMP]])
LogicalProject(ENAME=[$0], SAL=[$2])
LogicalTableScan(table=[[CATALOG, SALES, BONUS]])
{noformat}
In some cases, users may want to push Project past Join, but keep the join
condition unchanged, so we can upgrade *ProjectJoinTransposeRule* to allow user
choose whether to keep join condition
was:
Currently, when apply ProjectJoinTransposeRule, the join condition may be also
pushed, for example
for sql
The relation algebra
for sql
{noformat}
select emp.ename, sum(bonus.sal) from emp left outer join bonus on emp.ename =
bonus.ename and floor(emp.sal) > 10 group by emp.ename
{noformat}
is
{noformat}
LogicalAggregate(group=[{0}], EXPR$1=[SUM($1)])
LogicalProject(ENAME=[$1], SAL0=[$11])
LogicalJoin(condition=[AND(=($1, $9), >(FLOOR($5), 10))], joinType=[left])
LogicalTableScan(table=[[CATALOG, SALES, EMP]])
LogicalTableScan(table=[[CATALOG, SALES, BONUS]])
{noformat}
After applying *ProjectJoinTransposeRule*, the join condition 'floor(emp.sal)
> 10' is also pushed down,
{noformat}
LogicalAggregate(group=[{0}], EXPR$1=[SUM($1)])
LogicalProject(ENAME=[$0], SAL0=[$3])
LogicalJoin(condition=[AND(=($0, $2), $1)], joinType=[left])
LogicalProject(ENAME=[$1], >=[>(FLOOR($5), 10)])
LogicalTableScan(table=[[CATALOG, SALES, EMP]])
LogicalProject(ENAME=[$0], SAL=[$2])
LogicalTableScan(table=[[CATALOG, SALES, BONUS]])
{noformat}
In some cases, users may want to push Project past Join, but keep the join
condition unchanged, so we can improve *ProjectJoinTransposeRule* to allow user
choose whether to keep join filter
> Upgrade ProjectJoinTransposeRule to allow user choose whether to keep join
> condition
>
>
> Key: CALCITE-3919
> URL: https://issues.apache.org/jira/browse/CALCITE-3919
> Project: Calcite
> Issue Type: Improvement
>Reporter: Wang Yanlin
>Priority: Major
>
> Currently, when apply ProjectJoinTransposeRule, the join condition may be
> also pushed, for example
> for sql
> The relation algebra
> for sql
> {noformat}
> select emp.ename, sum(bonus.sal) from emp left outer join bonus on emp.ename
> = bonus.ename and floor(emp.sal) > 10 group by emp.ename
> {noformat}
> is
> {noformat}
> LogicalAggregate(group=[{0}], EXPR$1=[SUM($1)])
> LogicalProject(ENAME=[$1], SAL0=[$11])
> LogicalJoin(condition=[AND(=($1, $9), >(FLOOR($5), 10))], joinType=[left])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalTableScan(table=[[CATALOG, SALES, BONUS]])
> {noformat}
> After applying *ProjectJoinTransposeRule*, the join condition 'floor(emp.sal)
> > 10' is also pushed down,
> {noformat}
> LogicalAggregate(group=[{0}], EXPR$1=[SUM($1)])
> LogicalProject(ENAME=[$0], SAL0=[$3])
> LogicalJoin(condition=[AND(=($0, $2), $1)], joinType=[left])
> LogicalProject(ENAME=[$1], >=[>(FLOOR($5), 10)])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalProject(ENAME=[$0], SAL=[$2])
> LogicalTableScan(table=[[CATALOG, SALES, BONUS]])
> {noformat}
> In some cases, users may want to push Project past Join, but keep the join
> condition unchanged, so we can upgrade *ProjectJoinTransposeRule* to allow
> user choose whether to keep join condition
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3919) Upgrade ProjectJoinTransposeRule to allow user choose whether to keep join condition
[
https://issues.apache.org/jira/browse/CALCITE-3919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin updated CALCITE-3919:
-
Summary: Upgrade ProjectJoinTransposeRule to allow user choose whether to
keep join condition (was: Improve ProjectJoinTransposeRule to allow user
choose whether to keep join filter)
> Upgrade ProjectJoinTransposeRule to allow user choose whether to keep join
> condition
>
>
> Key: CALCITE-3919
> URL: https://issues.apache.org/jira/browse/CALCITE-3919
> Project: Calcite
> Issue Type: Improvement
>Reporter: Wang Yanlin
>Priority: Major
>
> Currently, when apply ProjectJoinTransposeRule, the join condition may be
> also pushed, for example
> for sql
> The relation algebra
> for sql
> {noformat}
> select emp.ename, sum(bonus.sal) from emp left outer join bonus on emp.ename
> = bonus.ename and floor(emp.sal) > 10 group by emp.ename
> {noformat}
> is
> {noformat}
> LogicalAggregate(group=[{0}], EXPR$1=[SUM($1)])
> LogicalProject(ENAME=[$1], SAL0=[$11])
> LogicalJoin(condition=[AND(=($1, $9), >(FLOOR($5), 10))], joinType=[left])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalTableScan(table=[[CATALOG, SALES, BONUS]])
> {noformat}
> After applying *ProjectJoinTransposeRule*, the join condition
> 'floor(emp.sal) > 10' is also pushed down,
> {noformat}
> LogicalAggregate(group=[{0}], EXPR$1=[SUM($1)])
> LogicalProject(ENAME=[$0], SAL0=[$3])
> LogicalJoin(condition=[AND(=($0, $2), $1)], joinType=[left])
> LogicalProject(ENAME=[$1], >=[>(FLOOR($5), 10)])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalProject(ENAME=[$0], SAL=[$2])
> LogicalTableScan(table=[[CATALOG, SALES, BONUS]])
> {noformat}
> In some cases, users may want to push Project past Join, but keep the join
> condition unchanged, so we can improve *ProjectJoinTransposeRule* to allow
> user choose whether to keep join filter
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-3919) Improve ProjectJoinTransposeRule to allow user choose whether to keep join filter
Wang Yanlin created CALCITE-3919:
Summary: Improve ProjectJoinTransposeRule to allow user choose
whether to keep join filter
Key: CALCITE-3919
URL: https://issues.apache.org/jira/browse/CALCITE-3919
Project: Calcite
Issue Type: Improvement
Reporter: Wang Yanlin
Currently, when apply ProjectJoinTransposeRule, the join condition may be also
pushed, for example
for sql
The relation algebra
for sql
{noformat}
select emp.ename, sum(bonus.sal) from emp left outer join bonus on emp.ename =
bonus.ename and floor(emp.sal) > 10 group by emp.ename
{noformat}
is
{noformat}
LogicalAggregate(group=[{0}], EXPR$1=[SUM($1)])
LogicalProject(ENAME=[$1], SAL0=[$11])
LogicalJoin(condition=[AND(=($1, $9), >(FLOOR($5), 10))], joinType=[left])
LogicalTableScan(table=[[CATALOG, SALES, EMP]])
LogicalTableScan(table=[[CATALOG, SALES, BONUS]])
{noformat}
After applying *ProjectJoinTransposeRule*, the join condition 'floor(emp.sal)
> 10' is also pushed down,
{noformat}
LogicalAggregate(group=[{0}], EXPR$1=[SUM($1)])
LogicalProject(ENAME=[$0], SAL0=[$3])
LogicalJoin(condition=[AND(=($0, $2), $1)], joinType=[left])
LogicalProject(ENAME=[$1], >=[>(FLOOR($5), 10)])
LogicalTableScan(table=[[CATALOG, SALES, EMP]])
LogicalProject(ENAME=[$0], SAL=[$2])
LogicalTableScan(table=[[CATALOG, SALES, BONUS]])
{noformat}
In some cases, users may want to push Project past Join, but keep the join
condition unchanged, so we can improve *ProjectJoinTransposeRule* to allow user
choose whether to keep join filter
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (CALCITE-3664) Sort in subquery is lost when converting SqlNode to Relnode
[
https://issues.apache.org/jira/browse/CALCITE-3664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin closed CALCITE-3664.
Resolution: Not A Problem
> Sort in subquery is lost when converting SqlNode to Relnode
> ---
>
> Key: CALCITE-3664
> URL: https://issues.apache.org/jira/browse/CALCITE-3664
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Major
>
> Lost sort in subquery when converting a SqlNode to Relnode, making its
> semantics changed.
> The test case to reproduce
> {code:java}
> // SqlToRelConverterTest
> @Test public void testSortInSubquery() {
> final String sql = "select ename from (select ename from emp order by
> ename) a";
> sql(sql).ok();
> }
> {code}
> This test case will success with this plan.
> {code:java}
>
>
>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3664) Sort in subquery is lost when converting SqlNode to Relnode
[
https://issues.apache.org/jira/browse/CALCITE-3664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17007306#comment-17007306
]
Wang Yanlin commented on CALCITE-3664:
--
Thanks [~hyuan] , now I got. I'll just close this jira.
But I'm still a little surprise to see that calcite drop sort in sub-query at
liberty.
I checked on mysql, the result is different if sort by different column inside
a sub-query.
> Sort in subquery is lost when converting SqlNode to Relnode
> ---
>
> Key: CALCITE-3664
> URL: https://issues.apache.org/jira/browse/CALCITE-3664
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Major
>
> Lost sort in subquery when converting a SqlNode to Relnode, making its
> semantics changed.
> The test case to reproduce
> {code:java}
> // SqlToRelConverterTest
> @Test public void testSortInSubquery() {
> final String sql = "select ename from (select ename from emp order by
> ename) a";
> sql(sql).ok();
> }
> {code}
> This test case will success with this plan.
> {code:java}
>
>
>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3664) Sort in subquery is lost when converting SqlNode to Relnode
[
https://issues.apache.org/jira/browse/CALCITE-3664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17006839#comment-17006839
]
Wang Yanlin commented on CALCITE-3664:
--
hi, [~jinxing6...@126.com], thanks for explanation.
I haven't digged into the code, but I added more test, like this
{code:java}
@Test public void testSortInSubquery() {
// final String sql = "select ename from (select ename from emp order by
deptno, ename) a";
// final String sql = "select ename from (select ename from emp order by
ename, deptno) a";
// final String sql = "select ename from (select ename from emp order by
job, deptno) a";
// final String sql = "select ename from (select ename from emp order by
job, ename, deptno) a";
final String sql = "select ename from (select ename from emp order by job,
ename, deptno) a";
sql(sql).ok();
}
{code}
All of them got the same relnode, how can the collation of emp satisfy all of
these orders?
> Sort in subquery is lost when converting SqlNode to Relnode
> ---
>
> Key: CALCITE-3664
> URL: https://issues.apache.org/jira/browse/CALCITE-3664
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Major
>
> Lost sort in subquery when converting a SqlNode to Relnode, making its
> semantics changed.
> The test case to reproduce
> {code:java}
> // SqlToRelConverterTest
> @Test public void testSortInSubquery() {
> final String sql = "select ename from (select ename from emp order by
> ename) a";
> sql(sql).ok();
> }
> {code}
> This test case will success with this plan.
> {code:java}
>
>
>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3664) Sort in subquery is lost when converting SqlNode to Relnode
[
https://issues.apache.org/jira/browse/CALCITE-3664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin updated CALCITE-3664:
-
Summary: Sort in subquery is lost when converting SqlNode to Relnode (was:
Lost sort in subquery when converting SqlNode to Relnode)
> Sort in subquery is lost when converting SqlNode to Relnode
> ---
>
> Key: CALCITE-3664
> URL: https://issues.apache.org/jira/browse/CALCITE-3664
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Major
>
> Lost sort in subquery when converting a SqlNode to Relnode, making its
> semantics changed.
> The test case to reproduce
> {code:java}
> // SqlToRelConverterTest
> @Test public void testSortInSubquery() {
> final String sql = "select ename from (select ename from emp order by
> ename) a";
> sql(sql).ok();
> }
> {code}
> This test case will success with this plan.
> {code:java}
>
>
>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (CALCITE-3664) Lost sort in subquery when converting SqlNode to Relnode
[
https://issues.apache.org/jira/browse/CALCITE-3664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin reassigned CALCITE-3664:
Assignee: Wang Yanlin
> Lost sort in subquery when converting SqlNode to Relnode
>
>
> Key: CALCITE-3664
> URL: https://issues.apache.org/jira/browse/CALCITE-3664
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Major
>
> Lost sort in subquery when converting a SqlNode to Relnode, making its
> semantics changed.
> The test case to reproduce
> {code:java}
> // SqlToRelConverterTest
> @Test public void testSortInSubquery() {
> final String sql = "select ename from (select ename from emp order by
> ename) a";
> sql(sql).ok();
> }
> {code}
> This test case will success with this plan.
> {code:java}
>
>
>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-3664) Lost sort in subquery when converting SqlNode to Relnode
Wang Yanlin created CALCITE-3664:
Summary: Lost sort in subquery when converting SqlNode to Relnode
Key: CALCITE-3664
URL: https://issues.apache.org/jira/browse/CALCITE-3664
Project: Calcite
Issue Type: Bug
Reporter: Wang Yanlin
Lost sort in subquery when converting a SqlNode to Relnode, making its
semantics changed.
The test case to reproduce
{code:java}
// SqlToRelConverterTest
@Test public void testSortInSubquery() {
final String sql = "select ename from (select ename from emp order by
ename) a";
sql(sql).ok();
}
{code}
This test case will success with this plan.
{code:java}
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (CALCITE-3651) NullPointerException when convert relational algebra that correlates TableFunctionScan
[
https://issues.apache.org/jira/browse/CALCITE-3651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin reassigned CALCITE-3651:
Assignee: Wang Yanlin
> NullPointerException when convert relational algebra that correlates
> TableFunctionScan
> ---
>
> Key: CALCITE-3651
> URL: https://issues.apache.org/jira/browse/CALCITE-3651
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Major
>
> Converting RelNode that correlate TableFunctionScan will cause NPE.
> {noformat}
> LogicalProject(product_class_id=[$0], product_id=[$1], brand_name=[$2],
> product_name=[$3], SKU=[$4], SRP=[$5], gross_weight=[$6], net_weight=[$7],
> recyclable_package=[$8], low_fat=[$9], units_per_case=[$10],
> cases_per_pallet=[$11], shelf_width=[$12], shelf_height=[$13],
> shelf_depth=[$14], I=[$15])
> LogicalCorrelate(correlation=[$cor0], joinType=[inner],
> requiredColumns=[{1}])
> JdbcTableScan(table=[[foodmart, product]])
> LogicalTableFunctionScan(invocation=[RAMP($cor0.product_id)],
> rowType=[RecordType(INTEGER I)])
> {noformat}
> Add this test case to reproduce
> {noformat}
> // RelToSqlConverterTest
> @Test public void testLateralCorrelate() {
> final String query = "select * from \"product\", lateral
> table(RAMP(\"product\".\"product_id\"))";
> sql(query).ok("");
> }
> {noformat}
> got
> {noformat}
> java.lang.RuntimeException: While invoking method 'public
> org.apache.calcite.rel.rel2sql.SqlImplementor$Result
> org.apache.calcite.rel.rel2sql.RelToSqlConverter.visit(org.apache.calcite.rel.core.Project)'
> at org.apache.calcite.util.ReflectUtil$2.invoke(ReflectUtil.java:527)
> at
> org.apache.calcite.rel.rel2sql.RelToSqlConverter.dispatch(RelToSqlConverter.java:126)
> at
> org.apache.calcite.rel.rel2sql.RelToSqlConverter.visitChild(RelToSqlConverter.java:132)
> at
> org.apache.calcite.rel.rel2sql.RelToSqlConverterTest.toSql(RelToSqlConverterTest.java:190)
> at
> org.apache.calcite.rel.rel2sql.RelToSqlConverterTest.access$200(RelToSqlConverterTest.java:94)
> at
> org.apache.calcite.rel.rel2sql.RelToSqlConverterTest$Sql.exec(RelToSqlConverterTest.java:4541)
> at
> org.apache.calcite.rel.rel2sql.RelToSqlConverterTest$Sql.ok(RelToSqlConverterTest.java:4516)
> at
> org.apache.calcite.rel.rel2sql.RelToSqlConverterTest.testLateralCorrelate(RelToSqlConverterTest.java:3741)
> 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(TestMethodTestDescripto
[jira] [Created] (CALCITE-3651) NullPointerException when convert relational algebra that correlates TableFunctionScan
Wang Yanlin created CALCITE-3651:
Summary: NullPointerException when convert relational algebra that
correlates TableFunctionScan
Key: CALCITE-3651
URL: https://issues.apache.org/jira/browse/CALCITE-3651
Project: Calcite
Issue Type: Bug
Reporter: Wang Yanlin
Converting RelNode that correlate TableFunctionScan will cause NPE.
{noformat}
LogicalProject(product_class_id=[$0], product_id=[$1], brand_name=[$2],
product_name=[$3], SKU=[$4], SRP=[$5], gross_weight=[$6], net_weight=[$7],
recyclable_package=[$8], low_fat=[$9], units_per_case=[$10],
cases_per_pallet=[$11], shelf_width=[$12], shelf_height=[$13],
shelf_depth=[$14], I=[$15])
LogicalCorrelate(correlation=[$cor0], joinType=[inner], requiredColumns=[{1}])
JdbcTableScan(table=[[foodmart, product]])
LogicalTableFunctionScan(invocation=[RAMP($cor0.product_id)],
rowType=[RecordType(INTEGER I)])
{noformat}
Add this test case to reproduce
{noformat}
// RelToSqlConverterTest
@Test public void testLateralCorrelate() {
final String query = "select * from \"product\", lateral
table(RAMP(\"product\".\"product_id\"))";
sql(query).ok("");
}
{noformat}
got
{noformat}
java.lang.RuntimeException: While invoking method 'public
org.apache.calcite.rel.rel2sql.SqlImplementor$Result
org.apache.calcite.rel.rel2sql.RelToSqlConverter.visit(org.apache.calcite.rel.core.Project)'
at org.apache.calcite.util.ReflectUtil$2.invoke(ReflectUtil.java:527)
at
org.apache.calcite.rel.rel2sql.RelToSqlConverter.dispatch(RelToSqlConverter.java:126)
at
org.apache.calcite.rel.rel2sql.RelToSqlConverter.visitChild(RelToSqlConverter.java:132)
at
org.apache.calcite.rel.rel2sql.RelToSqlConverterTest.toSql(RelToSqlConverterTest.java:190)
at
org.apache.calcite.rel.rel2sql.RelToSqlConverterTest.access$200(RelToSqlConverterTest.java:94)
at
org.apache.calcite.rel.rel2sql.RelToSqlConverterTest$Sql.exec(RelToSqlConverterTest.java:4541)
at
org.apache.calcite.rel.rel2sql.RelToSqlConverterTest$Sql.ok(RelToSqlConverterTest.java:4516)
at
org.apache.calcite.rel.rel2sql.RelToSqlConverterTest.testLateralCorrelate(RelToSqlConverterTest.java:3741)
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.supp
[jira] [Commented] (CALCITE-3639) JoinConditionPushRule fail to push filter to inputs
[
https://issues.apache.org/jira/browse/CALCITE-3639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17005089#comment-17005089
]
Wang Yanlin commented on CALCITE-3639:
--
Because it's left join, and no rows join success, so use null value for column
from right table.
> JoinConditionPushRule fail to push filter to inputs
> ---
>
> Key: CALCITE-3639
> URL: https://issues.apache.org/jira/browse/CALCITE-3639
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Major
>
> The relnode(without applying optimize rules) for the sql
> {code:java}
> String sql = "select empno, emp.deptno from emp left join dept\n"
> + " on emp.deptno = dept.deptno and empno = 10 and dept.deptno = 20";
> {code}
> is
> {code:java}
> LogicalProject(EMPNO=[$0], DEPTNO=[$7])
> LogicalJoin(condition=[AND(=($7, $9), =($0, 10), =($9, 20))],
> joinType=[left])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalTableScan(table=[[CATALOG, SALES, DEPT]])
> {code}
>
> After optimized with *JoinConditionPushRule*, the relnode becomes
> {code:java}
> LogicalProject(EMPNO=[$0], DEPTNO=[$7])
> LogicalJoin(condition=[AND(=($7, $9), =($0, 10))], joinType=[left])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalFilter(condition=[=($0, 20)])
> LogicalTableScan(table=[[CATALOG, SALES, DEPT]])
> {code}
> The optimize rule failed to push *empno = 10* to the left input, the better
> relnode should be
> {code:java}
> LogicalProject(EMPNO=[$0], DEPTNO=[$7])
> LogicalJoin(condition=[AND(=($7, $9))], joinType=[left])
> LogicalFilter(condition=[=($0, 10)])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalFilter(condition=[=($0, 20)])
> LogicalTableScan(table=[[CATALOG, SALES, DEPT]])
> {code}
>
> Add this test case to reproduce
> {code:java}
> // RelOptRulesTest
> @Test public void testFilterInLeftJoin() {
> String sql = "select empno, emp.deptno from emp left join dept\n"
> + " on emp.deptno = dept.deptno and empno = 10 and dept.deptno = 20";
> sql(sql).withRule(FilterJoinRule.JOIN).check();
> }
> // data for this case
>
>
>
>
>
>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (CALCITE-3639) JoinConditionPushRule fail to push filter to inputs
[
https://issues.apache.org/jira/browse/CALCITE-3639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin closed CALCITE-3639.
Resolution: Not A Bug
> JoinConditionPushRule fail to push filter to inputs
> ---
>
> Key: CALCITE-3639
> URL: https://issues.apache.org/jira/browse/CALCITE-3639
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Major
>
> The relnode(without applying optimize rules) for the sql
> {code:java}
> String sql = "select empno, emp.deptno from emp left join dept\n"
> + " on emp.deptno = dept.deptno and empno = 10 and dept.deptno = 20";
> {code}
> is
> {code:java}
> LogicalProject(EMPNO=[$0], DEPTNO=[$7])
> LogicalJoin(condition=[AND(=($7, $9), =($0, 10), =($9, 20))],
> joinType=[left])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalTableScan(table=[[CATALOG, SALES, DEPT]])
> {code}
>
> After optimized with *JoinConditionPushRule*, the relnode becomes
> {code:java}
> LogicalProject(EMPNO=[$0], DEPTNO=[$7])
> LogicalJoin(condition=[AND(=($7, $9), =($0, 10))], joinType=[left])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalFilter(condition=[=($0, 20)])
> LogicalTableScan(table=[[CATALOG, SALES, DEPT]])
> {code}
> The optimize rule failed to push *empno = 10* to the left input, the better
> relnode should be
> {code:java}
> LogicalProject(EMPNO=[$0], DEPTNO=[$7])
> LogicalJoin(condition=[AND(=($7, $9))], joinType=[left])
> LogicalFilter(condition=[=($0, 10)])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalFilter(condition=[=($0, 20)])
> LogicalTableScan(table=[[CATALOG, SALES, DEPT]])
> {code}
>
> Add this test case to reproduce
> {code:java}
> // RelOptRulesTest
> @Test public void testFilterInLeftJoin() {
> String sql = "select empno, emp.deptno from emp left join dept\n"
> + " on emp.deptno = dept.deptno and empno = 10 and dept.deptno = 20";
> sql(sql).withRule(FilterJoinRule.JOIN).check();
> }
> // data for this case
>
>
>
>
>
>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3639) JoinConditionPushRule fail to push filter to inputs
[
https://issues.apache.org/jira/browse/CALCITE-3639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17004120#comment-17004120
]
Wang Yanlin commented on CALCITE-3639:
--
Actually, this is not a bug.
{code:java}
LogicalProject(EMPNO=[$0], DEPTNO=[$7])
LogicalJoin(condition=[AND(=($7, $9), =($0, 10))], joinType=[left])
LogicalTableScan(table=[[CATALOG, SALES, EMP]])
LogicalFilter(condition=[=($0, 20)])
LogicalTableScan(table=[[CATALOG, SALES, DEPT]])
{code}
is not equal to
{code:java}
LogicalProject(EMPNO=[$0], DEPTNO=[$7])
LogicalJoin(condition=[AND(=($7, $9))], joinType=[left])
LogicalFilter(condition=[=($0, 10)])
LogicalTableScan(table=[[CATALOG, SALES, EMP]])
LogicalFilter(condition=[=($0, 20)])
LogicalTableScan(table=[[CATALOG, SALES, DEPT]])
{code}
Just conside the case below
{noformat}
mysql> select * from parts;
+--+-+
| num | orderOnhand |
+--+-+
|3 | 6 |
| 10 | 1 |
|8 | 0 |
+--+-+
3 rows in set (0.00 sec)
mysql> select * from supply;
+--+--+
| pnum | qty |
+--+--+
|3 |4 |
|3 |2 |
| 10 |1 |
+--+--+
3 rows in set (0.00 sec)
mysql> select * from parts left join supply on parts.num = supply.pnum and
parts.num < 0 and supply.pnum < 0;
+--+-+--+--+
| num | orderOnhand | pnum | qty |
+--+-+--+--+
|3 | 6 | NULL | NULL |
| 10 | 1 | NULL | NULL |
|8 | 0 | NULL | NULL |
+--+-+--+--+
3 rows in set (0.00 sec)
{noformat}
It's left join, and the filter in on condition, push it to left will reduce the
row number.
I'll just close this PR.
> JoinConditionPushRule fail to push filter to inputs
> ---
>
> Key: CALCITE-3639
> URL: https://issues.apache.org/jira/browse/CALCITE-3639
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Major
>
> The relnode(without applying optimize rules) for the sql
> {code:java}
> String sql = "select empno, emp.deptno from emp left join dept\n"
> + " on emp.deptno = dept.deptno and empno = 10 and dept.deptno = 20";
> {code}
> is
> {code:java}
> LogicalProject(EMPNO=[$0], DEPTNO=[$7])
> LogicalJoin(condition=[AND(=($7, $9), =($0, 10), =($9, 20))],
> joinType=[left])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalTableScan(table=[[CATALOG, SALES, DEPT]])
> {code}
>
> After optimized with *JoinConditionPushRule*, the relnode becomes
> {code:java}
> LogicalProject(EMPNO=[$0], DEPTNO=[$7])
> LogicalJoin(condition=[AND(=($7, $9), =($0, 10))], joinType=[left])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalFilter(condition=[=($0, 20)])
> LogicalTableScan(table=[[CATALOG, SALES, DEPT]])
> {code}
> The optimize rule failed to push *empno = 10* to the left input, the better
> relnode should be
> {code:java}
> LogicalProject(EMPNO=[$0], DEPTNO=[$7])
> LogicalJoin(condition=[AND(=($7, $9))], joinType=[left])
> LogicalFilter(condition=[=($0, 10)])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalFilter(condition=[=($0, 20)])
> LogicalTableScan(table=[[CATALOG, SALES, DEPT]])
> {code}
>
> Add this test case to reproduce
> {code:java}
> // RelOptRulesTest
> @Test public void testFilterInLeftJoin() {
> String sql = "select empno, emp.deptno from emp left join dept\n"
> + " on emp.deptno = dept.deptno and empno = 10 and dept.deptno = 20";
> sql(sql).withRule(FilterJoinRule.JOIN).check();
> }
> // data for this case
>
>
>
>
>
>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-3639) JoinConditionPushRule fail to push filter to inputs
Wang Yanlin created CALCITE-3639:
Summary: JoinConditionPushRule fail to push filter to inputs
Key: CALCITE-3639
URL: https://issues.apache.org/jira/browse/CALCITE-3639
Project: Calcite
Issue Type: Bug
Reporter: Wang Yanlin
The relnode(without applying optimize rules) for the sql
{code:java}
String sql = "select empno, emp.deptno from emp left join dept\n"
+ " on emp.deptno = dept.deptno and empno = 10 and dept.deptno = 20";
{code}
is
{code:java}
LogicalProject(EMPNO=[$0], DEPTNO=[$7])
LogicalJoin(condition=[AND(=($7, $9), =($0, 10), =($9, 20))], joinType=[left])
LogicalTableScan(table=[[CATALOG, SALES, EMP]])
LogicalTableScan(table=[[CATALOG, SALES, DEPT]])
{code}
After optimized with *JoinConditionPushRule*, the relnode becomes
{code:java}
LogicalProject(EMPNO=[$0], DEPTNO=[$7])
LogicalJoin(condition=[AND(=($7, $9), =($0, 10))], joinType=[left])
LogicalTableScan(table=[[CATALOG, SALES, EMP]])
LogicalFilter(condition=[=($0, 20)])
LogicalTableScan(table=[[CATALOG, SALES, DEPT]])
{code}
The optimize rule failed to push *empno = 10* to the left input, the better
relnode should be
{code:java}
LogicalProject(EMPNO=[$0], DEPTNO=[$7])
LogicalJoin(condition=[AND(=($7, $9))], joinType=[left])
LogicalFilter(condition=[=($0, 10)])
LogicalTableScan(table=[[CATALOG, SALES, EMP]])
LogicalFilter(condition=[=($0, 20)])
LogicalTableScan(table=[[CATALOG, SALES, DEPT]])
{code}
Add this test case to reproduce
{code:java}
// RelOptRulesTest
@Test public void testFilterInLeftJoin() {
String sql = "select empno, emp.deptno from emp left join dept\n"
+ " on emp.deptno = dept.deptno and empno = 10 and dept.deptno = 20";
sql(sql).withRule(FilterJoinRule.JOIN).check();
}
// data for this case
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (CALCITE-3639) JoinConditionPushRule fail to push filter to inputs
[
https://issues.apache.org/jira/browse/CALCITE-3639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin reassigned CALCITE-3639:
Assignee: Wang Yanlin
> JoinConditionPushRule fail to push filter to inputs
> ---
>
> Key: CALCITE-3639
> URL: https://issues.apache.org/jira/browse/CALCITE-3639
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Major
>
> The relnode(without applying optimize rules) for the sql
> {code:java}
> String sql = "select empno, emp.deptno from emp left join dept\n"
> + " on emp.deptno = dept.deptno and empno = 10 and dept.deptno = 20";
> {code}
> is
> {code:java}
> LogicalProject(EMPNO=[$0], DEPTNO=[$7])
> LogicalJoin(condition=[AND(=($7, $9), =($0, 10), =($9, 20))],
> joinType=[left])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalTableScan(table=[[CATALOG, SALES, DEPT]])
> {code}
>
> After optimized with *JoinConditionPushRule*, the relnode becomes
> {code:java}
> LogicalProject(EMPNO=[$0], DEPTNO=[$7])
> LogicalJoin(condition=[AND(=($7, $9), =($0, 10))], joinType=[left])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalFilter(condition=[=($0, 20)])
> LogicalTableScan(table=[[CATALOG, SALES, DEPT]])
> {code}
> The optimize rule failed to push *empno = 10* to the left input, the better
> relnode should be
> {code:java}
> LogicalProject(EMPNO=[$0], DEPTNO=[$7])
> LogicalJoin(condition=[AND(=($7, $9))], joinType=[left])
> LogicalFilter(condition=[=($0, 10)])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalFilter(condition=[=($0, 20)])
> LogicalTableScan(table=[[CATALOG, SALES, DEPT]])
> {code}
>
> Add this test case to reproduce
> {code:java}
> // RelOptRulesTest
> @Test public void testFilterInLeftJoin() {
> String sql = "select empno, emp.deptno from emp left join dept\n"
> + " on emp.deptno = dept.deptno and empno = 10 and dept.deptno = 20";
> sql(sql).withRule(FilterJoinRule.JOIN).check();
> }
> // data for this case
>
>
>
>
>
>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3595) Test infrastructure overwrites reference log with wrong results
[ https://issues.apache.org/jira/browse/CALCITE-3595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16998208#comment-16998208 ] Wang Yanlin commented on CALCITE-3595: -- I came across this problem very often when debug, it's a little annoying, so I create PR try to fix. > Test infrastructure overwrites reference log with wrong results > --- > > Key: CALCITE-3595 > URL: https://issues.apache.org/jira/browse/CALCITE-3595 > Project: Calcite > Issue Type: Bug > Components: build >Reporter: Julian Hyde >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > When I add a test case to a test that is based on DiffRepository (such as > SqlPrettyWriterTest), and run it in Intellij, the first time gives an error > because the actual output does not match the expected output. This is good. > I would expect that if I run it again, it will fail again, but it does not. > I'm not sure exactly what is going on, but maybe the test is reading from an > output file instead of a reference log. This was probably broken during the > migration to gradle, because the paths for reference logs have all changed. > This bug prevents me from using the workflow where I add a test case, run it, > and when it fails, change the code until the output looks right, then > overwrite the reference log. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3495) RelDecorrelator generate plan with different semantics when handle Aggregate
[
https://issues.apache.org/jira/browse/CALCITE-3495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16998030#comment-16998030
]
Wang Yanlin commented on CALCITE-3495:
--
Thanks [~jinxing6...@126.com], I create a PR tries to fail the decorrelation
for aggrate having COUNT.
And, it's sill work in progress, comments are welcome.
[https://github.com/apache/calcite/pull/1670]
> RelDecorrelator generate plan with different semantics when handle Aggregate
>
>
> Key: CALCITE-3495
> URL: https://issues.apache.org/jira/browse/CALCITE-3495
> Project: Calcite
> Issue Type: Bug
>Reporter: Jin Xing
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Given below Sql and data
> {code:java}
> SELECT deptno FROM dept A where deptno in
> (SELECT count(1) FROM emp B where A.deptno = B.deptno)
> -
> Data of dept:
> deptno
> 0
> 1
>
> Data of emp:
> deptno
> 1{code}
> From the Sql semantics by nest-loop join, we will expect the result as
> {code:java}
> Result:
> deptno
> 0
> 1{code}
> However the decorrelated plan is as below:
> {code:java}
> LogicalProject(DEPTNO=[$0])
> LogicalJoin(condition=[=($0, $3)], joinType=[inner])
> LogicalTableScan(table=[[CATALOG, SALES, DEPT]])
> LogicalFilter(condition=[=($1, $0)])
> LogicalProject(EXPR$0=[$1], DEPTNO=[$0])
> LogicalAggregate(group=[{0}], EXPR$0=[COUNT()])
> LogicalProject(DEPTNO=[$7], $f0=[1])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> {code}
> The result of this plan is as below:
> {code:java}
> Result:
> deptno
> 1
> {code}
> As we can see the two above results are different.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3495) RelDecorrelator generate plan with different semantics when handle Aggregate
[
https://issues.apache.org/jira/browse/CALCITE-3495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16998023#comment-16998023
]
Wang Yanlin commented on CALCITE-3495:
--
In this case, I think *SUM* is fine, when no input, it generate NULL value.
> RelDecorrelator generate plan with different semantics when handle Aggregate
>
>
> Key: CALCITE-3495
> URL: https://issues.apache.org/jira/browse/CALCITE-3495
> Project: Calcite
> Issue Type: Bug
>Reporter: Jin Xing
>Priority: Major
>
> Given below Sql and data
> {code:java}
> SELECT deptno FROM dept A where deptno in
> (SELECT count(1) FROM emp B where A.deptno = B.deptno)
> -
> Data of dept:
> deptno
> 0
> 1
>
> Data of emp:
> deptno
> 1{code}
> From the Sql semantics by nest-loop join, we will expect the result as
> {code:java}
> Result:
> deptno
> 0
> 1{code}
> However the decorrelated plan is as below:
> {code:java}
> LogicalProject(DEPTNO=[$0])
> LogicalJoin(condition=[=($0, $3)], joinType=[inner])
> LogicalTableScan(table=[[CATALOG, SALES, DEPT]])
> LogicalFilter(condition=[=($1, $0)])
> LogicalProject(EXPR$0=[$1], DEPTNO=[$0])
> LogicalAggregate(group=[{0}], EXPR$0=[COUNT()])
> LogicalProject(DEPTNO=[$7], $f0=[1])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> {code}
> The result of this plan is as below:
> {code:java}
> Result:
> deptno
> 1
> {code}
> As we can see the two above results are different.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3605) Semantics of relation operator changed after decorrelated
[
https://issues.apache.org/jira/browse/CALCITE-3605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16997858#comment-16997858
]
Wang Yanlin commented on CALCITE-3605:
--
Yes, same with CALCITE-3495, I'll close this jira. Let's continue discuss in
CALCITE-3495
> Semantics of relation operator changed after decorrelated
> -
>
> Key: CALCITE-3605
> URL: https://issues.apache.org/jira/browse/CALCITE-3605
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Major
>
> For sql
> {code:java}
> final String sql = "select deptno from (select deptno, empno from emp) p\n"
> + "where empno in\n"
> + "(select count(*) from dept where p.deptno = dept.deptno)";
> {code}
> before decorrelated, the relnode tree is
> {code:java}
> LogicalProject(DEPTNO=[$0])
> LogicalProject(DEPTNO=[$0], EMPNO=[$1])
> LogicalFilter(condition=[=($1, $2)])
> LogicalCorrelate(correlation=[$cor0], joinType=[inner],
> requiredColumns=[{0}])
> LogicalProject(DEPTNO=[$7], EMPNO=[$0])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalAggregate(group=[{}], EXPR$0=[COUNT()])
> LogicalProject($f0=[0])
> LogicalFilter(condition=[=($cor0.DEPTNO, $0)])
> LogicalTableScan(table=[[CATALOG, SALES, DEPT]])
> {code}
> after decorrelatd, the relnode tree is
> {code:java}
> LogicalProject(DEPTNO=[$0])
> LogicalJoin(condition=[AND(=($0, $2), =($1, $3))], joinType=[inner])
> LogicalProject(DEPTNO=[$7], EMPNO=[$0])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalAggregate(group=[{0}], EXPR$0=[COUNT()])
> LogicalProject(DEPTNO=[$0], $f0=[0])
> LogicalTableScan(table=[[CATALOG, SALES, DEPT]])
> {code}
> however, these two relnode trees have different semantics.
> Assume, the data in dept and emp is as below
> {code:java}
> EMP (deptno, empno)
> 3, 6
> 10, 1
> 8, 0
> DEPT (deptno, name)
> 3, "a"
> 10, "b"
> {code}
> The output of the sql should be
> +--+
> |10|
> |8|
> +--+
> but the output of the relnode after decorrelated is
> +--+
> |10|
> +--+
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (CALCITE-3605) Semantics of relation operator changed after decorrelated
[
https://issues.apache.org/jira/browse/CALCITE-3605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin closed CALCITE-3605.
Resolution: Duplicate
> Semantics of relation operator changed after decorrelated
> -
>
> Key: CALCITE-3605
> URL: https://issues.apache.org/jira/browse/CALCITE-3605
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Major
>
> For sql
> {code:java}
> final String sql = "select deptno from (select deptno, empno from emp) p\n"
> + "where empno in\n"
> + "(select count(*) from dept where p.deptno = dept.deptno)";
> {code}
> before decorrelated, the relnode tree is
> {code:java}
> LogicalProject(DEPTNO=[$0])
> LogicalProject(DEPTNO=[$0], EMPNO=[$1])
> LogicalFilter(condition=[=($1, $2)])
> LogicalCorrelate(correlation=[$cor0], joinType=[inner],
> requiredColumns=[{0}])
> LogicalProject(DEPTNO=[$7], EMPNO=[$0])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalAggregate(group=[{}], EXPR$0=[COUNT()])
> LogicalProject($f0=[0])
> LogicalFilter(condition=[=($cor0.DEPTNO, $0)])
> LogicalTableScan(table=[[CATALOG, SALES, DEPT]])
> {code}
> after decorrelatd, the relnode tree is
> {code:java}
> LogicalProject(DEPTNO=[$0])
> LogicalJoin(condition=[AND(=($0, $2), =($1, $3))], joinType=[inner])
> LogicalProject(DEPTNO=[$7], EMPNO=[$0])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalAggregate(group=[{0}], EXPR$0=[COUNT()])
> LogicalProject(DEPTNO=[$0], $f0=[0])
> LogicalTableScan(table=[[CATALOG, SALES, DEPT]])
> {code}
> however, these two relnode trees have different semantics.
> Assume, the data in dept and emp is as below
> {code:java}
> EMP (deptno, empno)
> 3, 6
> 10, 1
> 8, 0
> DEPT (deptno, name)
> 3, "a"
> 10, "b"
> {code}
> The output of the sql should be
> +--+
> |10|
> |8|
> +--+
> but the output of the relnode after decorrelated is
> +--+
> |10|
> +--+
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (CALCITE-3596) Sql query in javadoc of OverScope class has syntax error
[
https://issues.apache.org/jira/browse/CALCITE-3596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin closed CALCITE-3596.
Resolution: Not A Problem
> Sql query in javadoc of OverScope class has syntax error
>
>
> Key: CALCITE-3596
> URL: https://issues.apache.org/jira/browse/CALCITE-3596
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Priority: Minor
>
> The sql in class of OverScope
> (https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/validate/OverScope.java#L33)
> has syntax error, cause SqlParseException
> {code:java}
> // SqlToRelConverterTest
> @Test public void testOver() {
> /*
> final String sql = "SELECT * FROM\n"
> + "(SELECT deptno, count(*) OVER (ORDER BY empno RANGE BETWEEN 2
> PRECEDING AND 2 FOLLOWING) FROM emp) ";
> */
> final String sql = "SELECT name FROM\n"
> + "(SELECT * FROM\n"
> + "emp OVER (ORDER BY empno RANGE BETWEEN 2 PRECEDING AND 2
> FOLLOWING))";
> sql(sql).ok();
> }
> {code}
> got
> {code:java}
> Caused by: org.apache.calcite.sql.parser.impl.ParseException: Encountered
> "OVER" at line 3, column 5.
> Was expecting one of:
> "AS" ...
> "EXCEPT" ...
> "EXTEND" ...
> "FETCH" ...
> "FOR" ...
> "GROUP" ...
> "HAVING" ...
> "INTERSECT" ...
> "LIMIT" ...
> "MATCH_RECOGNIZE" ...
> "OFFSET" ...
> "ORDER" ...
> "MINUS" ...
> "TABLESAMPLE" ...
> "UNION" ...
> "WHERE" ...
> "WINDOW" ...
> "(" ...
> ")" ...
> ...
> ...
> ...
> ...
> ...
> ...
> "NATURAL" ...
> "JOIN" ...
> "INNER" ...
> "LEFT" ...
> "RIGHT" ...
> "FULL" ...
> "CROSS" ...
> "," ...
> "OUTER" ...
> "." ...
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3596) Sql query in javadoc of OverScope class has syntax error
[
https://issues.apache.org/jira/browse/CALCITE-3596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16997776#comment-16997776
]
Wang Yanlin commented on CALCITE-3596:
--
[~julianhyde] Thans for your detail explanation, now I understand, I'll just
close the jira.
> Sql query in javadoc of OverScope class has syntax error
>
>
> Key: CALCITE-3596
> URL: https://issues.apache.org/jira/browse/CALCITE-3596
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Priority: Minor
>
> The sql in class of OverScope
> (https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/validate/OverScope.java#L33)
> has syntax error, cause SqlParseException
> {code:java}
> // SqlToRelConverterTest
> @Test public void testOver() {
> /*
> final String sql = "SELECT * FROM\n"
> + "(SELECT deptno, count(*) OVER (ORDER BY empno RANGE BETWEEN 2
> PRECEDING AND 2 FOLLOWING) FROM emp) ";
> */
> final String sql = "SELECT name FROM\n"
> + "(SELECT * FROM\n"
> + "emp OVER (ORDER BY empno RANGE BETWEEN 2 PRECEDING AND 2
> FOLLOWING))";
> sql(sql).ok();
> }
> {code}
> got
> {code:java}
> Caused by: org.apache.calcite.sql.parser.impl.ParseException: Encountered
> "OVER" at line 3, column 5.
> Was expecting one of:
> "AS" ...
> "EXCEPT" ...
> "EXTEND" ...
> "FETCH" ...
> "FOR" ...
> "GROUP" ...
> "HAVING" ...
> "INTERSECT" ...
> "LIMIT" ...
> "MATCH_RECOGNIZE" ...
> "OFFSET" ...
> "ORDER" ...
> "MINUS" ...
> "TABLESAMPLE" ...
> "UNION" ...
> "WHERE" ...
> "WINDOW" ...
> "(" ...
> ")" ...
> ...
> ...
> ...
> ...
> ...
> ...
> "NATURAL" ...
> "JOIN" ...
> "INNER" ...
> "LEFT" ...
> "RIGHT" ...
> "FULL" ...
> "CROSS" ...
> "," ...
> "OUTER" ...
> "." ...
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3605) Semantics of relation operator changed after decorrelated
[
https://issues.apache.org/jira/browse/CALCITE-3605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16997762#comment-16997762
]
Wang Yanlin commented on CALCITE-3605:
--
{code:java}
// RelOptRulesTest
@Test public void testDecorrelateIn() throws Exception {
final String sql = "select deptno from (select deptno, empno from emp) p\n"
+ "where empno in\n"
+ "(select count(*) from dept where p.deptno = dept.deptno)";
checkSubQuery(sql).withLateDecorrelation(true).check();
}
{code}
and the plan is
{code:java}
{code}
> Semantics of relation operator changed after decorrelated
> -
>
> Key: CALCITE-3605
> URL: https://issues.apache.org/jira/browse/CALCITE-3605
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Major
>
> For sql
> {code:java}
> final String sql = "select deptno from (select deptno, empno from emp) p\n"
> + "where empno in\n"
> + "(select count(*) from dept where p.deptno = dept.deptno)";
> {code}
> before decorrelated, the relnode tree is
> {code:java}
> LogicalProject(DEPTNO=[$0])
> LogicalProject(DEPTNO=[$0], EMPNO=[$1])
> LogicalFilter(condition=[=($1, $2)])
> LogicalCorrelate(correlation=[$cor0], joinType=[inner],
> requiredColumns=[{0}])
> LogicalProject(DEPTNO=[$7], EMPNO=[$0])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalAggregate(group=[{}], EXPR$0=[COUNT()])
> LogicalProject($f0=[0])
> LogicalFilter(condition=[=($cor0.DEPTNO, $0)])
> LogicalTableScan(table=[[CATALOG, SALES, DEPT]])
> {code}
> after decorrelatd, the relnode tree is
> {code:java}
> LogicalProject(DEPTNO=[$0])
> LogicalJoin(condition=[AND(=($0, $2), =($1, $3))], joinType=[inner])
> LogicalProject(DEPTNO=[$7], EMPNO=[$0])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalAggregate(group=[{0}], EXPR$0=[COUNT()])
> LogicalProject(DEPTNO=[$0], $f0=[0])
> LogicalTableScan(table=[[CATALOG, SALES, DEPT]])
> {code}
> however, these two relnode trees have different semantics.
> Assume, the data in dept and emp is as below
> {code:java}
> EMP (deptno, empno)
> 3, 6
> 10, 1
> 8, 0
> DEPT (deptno, name)
> 3, "a"
> 10, "b"
> {code}
> The output of the sql should be
> +--+
> |10|
> |8|
> +--+
> but the output of the relnode after decorrelated is
> +--+
> |10|
> +--+
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (CALCITE-3605) Semantics of relation operator changed after decorrelated
[
https://issues.apache.org/jira/browse/CALCITE-3605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin reassigned CALCITE-3605:
Assignee: Wang Yanlin
> Semantics of relation operator changed after decorrelated
> -
>
> Key: CALCITE-3605
> URL: https://issues.apache.org/jira/browse/CALCITE-3605
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Major
>
> For sql
> {code:java}
> final String sql = "select deptno from (select deptno, empno from emp) p\n"
> + "where empno in\n"
> + "(select count(*) from dept where p.deptno = dept.deptno)";
> {code}
> before decorrelated, the relnode tree is
> {code:java}
> LogicalProject(DEPTNO=[$0])
> LogicalProject(DEPTNO=[$0], EMPNO=[$1])
> LogicalFilter(condition=[=($1, $2)])
> LogicalCorrelate(correlation=[$cor0], joinType=[inner],
> requiredColumns=[{0}])
> LogicalProject(DEPTNO=[$7], EMPNO=[$0])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalAggregate(group=[{}], EXPR$0=[COUNT()])
> LogicalProject($f0=[0])
> LogicalFilter(condition=[=($cor0.DEPTNO, $0)])
> LogicalTableScan(table=[[CATALOG, SALES, DEPT]])
> {code}
> after decorrelatd, the relnode tree is
> {code:java}
> LogicalProject(DEPTNO=[$0])
> LogicalJoin(condition=[AND(=($0, $2), =($1, $3))], joinType=[inner])
> LogicalProject(DEPTNO=[$7], EMPNO=[$0])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalAggregate(group=[{0}], EXPR$0=[COUNT()])
> LogicalProject(DEPTNO=[$0], $f0=[0])
> LogicalTableScan(table=[[CATALOG, SALES, DEPT]])
> {code}
> however, these two relnode trees have different semantics.
> Assume, the data in dept and emp is as below
> {code:java}
> EMP (deptno, empno)
> 3, 6
> 10, 1
> 8, 0
> DEPT (deptno, name)
> 3, "a"
> 10, "b"
> {code}
> The output of the sql should be
> +--+
> |10|
> |8|
> +--+
> but the output of the relnode after decorrelated is
> +--+
> |10|
> +--+
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-3605) Semantics of relation operator changed after decorrelated
Wang Yanlin created CALCITE-3605:
Summary: Semantics of relation operator changed after decorrelated
Key: CALCITE-3605
URL: https://issues.apache.org/jira/browse/CALCITE-3605
Project: Calcite
Issue Type: Bug
Reporter: Wang Yanlin
For sql
{code:java}
final String sql = "select deptno from (select deptno, empno from emp) p\n"
+ "where empno in\n"
+ "(select count(*) from dept where p.deptno = dept.deptno)";
{code}
before decorrelated, the relnode tree is
{code:java}
LogicalProject(DEPTNO=[$0])
LogicalProject(DEPTNO=[$0], EMPNO=[$1])
LogicalFilter(condition=[=($1, $2)])
LogicalCorrelate(correlation=[$cor0], joinType=[inner],
requiredColumns=[{0}])
LogicalProject(DEPTNO=[$7], EMPNO=[$0])
LogicalTableScan(table=[[CATALOG, SALES, EMP]])
LogicalAggregate(group=[{}], EXPR$0=[COUNT()])
LogicalProject($f0=[0])
LogicalFilter(condition=[=($cor0.DEPTNO, $0)])
LogicalTableScan(table=[[CATALOG, SALES, DEPT]])
{code}
after decorrelatd, the relnode tree is
{code:java}
LogicalProject(DEPTNO=[$0])
LogicalJoin(condition=[AND(=($0, $2), =($1, $3))], joinType=[inner])
LogicalProject(DEPTNO=[$7], EMPNO=[$0])
LogicalTableScan(table=[[CATALOG, SALES, EMP]])
LogicalAggregate(group=[{0}], EXPR$0=[COUNT()])
LogicalProject(DEPTNO=[$0], $f0=[0])
LogicalTableScan(table=[[CATALOG, SALES, DEPT]])
{code}
however, these two relnode trees have different semantics.
Assume, the data in dept and emp is as below
{code:java}
EMP (deptno, empno)
3, 6
10, 1
8, 0
DEPT (deptno, name)
3, "a"
10, "b"
{code}
The output of the sql should be
+--+
|10|
|8|
+--+
but the output of the relnode after decorrelated is
+--+
|10|
+--+
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3587) RexBuilder may lose decimal fraction for creating literal with DECIMAL type
[
https://issues.apache.org/jira/browse/CALCITE-3587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16997117#comment-16997117
]
Wang Yanlin commented on CALCITE-3587:
--
Thanks for detail description [~danny0405] [~julianhyde]
I agree it should throw an exception .
> RexBuilder may lose decimal fraction for creating literal with DECIMAL type
> ---
>
> Key: CALCITE-3587
> URL: https://issues.apache.org/jira/browse/CALCITE-3587
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Major
> Labels: pull-request-available
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> this test
> {code:java}
> // RexBuilderTest
> @Test public void testDecimal() {
> final RelDataTypeFactory typeFactory =
> new SqlTypeFactoryImpl(RelDataTypeSystem.DEFAULT);
> final RelDataType type = typeFactory.createSqlType(SqlTypeName.DECIMAL, 4, 2);
> final RexBuilder builder = new RexBuilder(typeFactory);
> final RexLiteral literal = (RexLiteral) builder.makeLiteral(12.3, type,
> false);
> Comparable value = literal.getValue();
> assertThat(value.toString(), is("12.3"));
> }
> {code}
> fails with message
> {code:java}
> java.lang.AssertionError:
> Expected: is "12.3"
> but: was "12"
> Expected :12.3
> Actual :12
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3587) RexBuilder may lose decimal fraction for creating literal with DECIMAL type
[
https://issues.apache.org/jira/browse/CALCITE-3587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16995424#comment-16995424
]
Wang Yanlin commented on CALCITE-3587:
--
DECIMAL is fixed point type, when creating RexLiteral with DECIMAL type, should
not only use the integer part, need the decimal fraction part as well
> RexBuilder may lose decimal fraction for creating literal with DECIMAL type
> ---
>
> Key: CALCITE-3587
> URL: https://issues.apache.org/jira/browse/CALCITE-3587
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Assignee: Wang Yanlin
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> this test
> {code:java}
> // RexBuilderTest
> @Test public void testDecimal() {
> final RelDataTypeFactory typeFactory =
> new SqlTypeFactoryImpl(RelDataTypeSystem.DEFAULT);
> final RelDataType type = typeFactory.createSqlType(SqlTypeName.DECIMAL, 4, 2);
> final RexBuilder builder = new RexBuilder(typeFactory);
> final RexLiteral literal = (RexLiteral) builder.makeLiteral(12.3, type,
> false);
> Comparable value = literal.getValue();
> assertThat(value.toString(), is("12.3"));
> }
> {code}
> fails with message
> {code:java}
> java.lang.AssertionError:
> Expected: is "12.3"
> but: was "12"
> Expected :12.3
> Actual :12
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
