[jira] [Commented] (CALCITE-4136) ReduceExpressionsRule.FILTER_INSTANCE cannot be initialized by some JVM
[
https://issues.apache.org/jira/browse/CALCITE-4136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17162702#comment-17162702
]
Enrico Olivelli commented on CALCITE-4136:
--
[https://adoptopenjdk.net/]
{code:java}
mvn -v
Java version: 14, vendor: AdoptOpenJDK, runtime:
/Library/Java/JavaVirtualMachines/adoptopenjdk-14.jdk/Contents/Home
Default locale: it_IT, platform encoding: UTF-8
OS name: "mac os x", version: "10.15.4", arch: "x86_64", family: "mac"
{code}
IIRC correctly the same problem was also on TravisCI on JDK11, but I do not
have the logs anymore.
> ReduceExpressionsRule.FILTER_INSTANCE cannot be initialized by some JVM
> ---
>
> Key: CALCITE-4136
> URL: https://issues.apache.org/jira/browse/CALCITE-4136
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Stamatis Zampetakis
>Priority: Major
> Attachments: DeprecatedRulesAreNull.png
>
>
> In certain JVM implementations the field cannot be initialized leading to
> {{NullPointerException}} when using the rule.
> Few stacktraces are given below:
> {noformat}
> Caused by: java.lang.NullPointerException: at index 0
> at
> com.onwbp.com.google.common.collect.ObjectArrays.checkElementNotNull(ObjectArrays.java:239)
> at
> com.onwbp.com.google.common.collect.ObjectArrays.checkElementsNotNull(ObjectArrays.java:230)
> at
> com.onwbp.com.google.common.collect.ObjectArrays.checkElementsNotNull(ObjectArrays.java:225)
> at
> com.onwbp.com.google.common.collect.ImmutableList.construct(ImmutableList.java:281)
> at
> com.onwbp.com.google.common.collect.ImmutableList.copyOf(ImmutableList.java:239)
> at
> com.onwbp.com.google.common.collect.ImmutableList.copyOf(ImmutableList.java:209)
> at com.onwbp.org.apache.calcite.tools.RuleSets.ofList(RuleSets.java:41)
> {noformat}
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.calcite.plan.AbstractRelOptPlanner.addRule(AbstractRelOptPlanner.java:147)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.addRule(VolcanoPlanner.java:416)
> at herddb.sql.CalcitePlanner.runPlanner(CalcitePlanner.java:576)
> at herddb.sql.CalcitePlanner.translate(CalcitePlanner.java:331)
> at herddb.core.TestUtils.scan(TestUtils.java:70)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4136) ReduceExpressionsRule.FILTER_INSTANCE cannot be initialized by some JVM
[
https://issues.apache.org/jira/browse/CALCITE-4136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17162657#comment-17162657
]
Enrico Olivelli commented on CALCITE-4136:
--
The second stacktrace is on HerdDB 0.18.0 (updating Calcite dependency to
1.24rc0), on AdoptOpenJDK14 (linux and Mac)
> ReduceExpressionsRule.FILTER_INSTANCE cannot be initialized by some JVM
> ---
>
> Key: CALCITE-4136
> URL: https://issues.apache.org/jira/browse/CALCITE-4136
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Stamatis Zampetakis
>Priority: Major
>
> In certain JVM implementations the field cannot be initialized leading to
> {{NullPointerException}} when using the rule.
> Few stacktraces are given below:
> {noformat}
> Caused by: java.lang.NullPointerException: at index 0
> at
> com.onwbp.com.google.common.collect.ObjectArrays.checkElementNotNull(ObjectArrays.java:239)
> at
> com.onwbp.com.google.common.collect.ObjectArrays.checkElementsNotNull(ObjectArrays.java:230)
> at
> com.onwbp.com.google.common.collect.ObjectArrays.checkElementsNotNull(ObjectArrays.java:225)
> at
> com.onwbp.com.google.common.collect.ImmutableList.construct(ImmutableList.java:281)
> at
> com.onwbp.com.google.common.collect.ImmutableList.copyOf(ImmutableList.java:239)
> at
> com.onwbp.com.google.common.collect.ImmutableList.copyOf(ImmutableList.java:209)
> at com.onwbp.org.apache.calcite.tools.RuleSets.ofList(RuleSets.java:41)
> {noformat}
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.calcite.plan.AbstractRelOptPlanner.addRule(AbstractRelOptPlanner.java:147)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.addRule(VolcanoPlanner.java:416)
> at herddb.sql.CalcitePlanner.runPlanner(CalcitePlanner.java:576)
> at herddb.sql.CalcitePlanner.translate(CalcitePlanner.java:331)
> at herddb.core.TestUtils.scan(TestUtils.java:70)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-2395) Support SELECT xxx FROM TABLE FOR UPDATE syntax
[ https://issues.apache.org/jira/browse/CALCITE-2395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17146049#comment-17146049 ] Enrico Olivelli commented on CALCITE-2395: -- I have got another request for this feature [https://github.com/diennea/herddb/issues/631] I hope that someone has time to pick up this work, I am not sure I have time in the short time. > Support SELECT xxx FROM TABLE FOR UPDATE syntax > --- > > Key: CALCITE-2395 > URL: https://issues.apache.org/jira/browse/CALCITE-2395 > Project: Calcite > Issue Type: New Feature > Components: core >Affects Versions: 1.16.0 >Reporter: Enrico Olivelli >Priority: Major > Labels: pull-request-available > > I am using Calcite SQL Parser and Volcano Planner. > I need to support SQL syntax > SELECT ... FROM table FOR UPDATE > > see for instance PostGre docs > [https://www.postgresql.org/docs/9.5/static/sql-select.html.] > > I would like at least to support this syntax at SQL Parser level, the 'for > update' spec should be reported by the RelNode so that the system can take it > into account and perform explicit locking. > > Linked downstream project issue: > https://github.com/diennea/herddb/issues/228 > > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3997) Problem with MERGE JOIN: java.lang.AssertionError: cannot merge join: left input is not sorted on left keys
[ https://issues.apache.org/jira/browse/CALCITE-3997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17108053#comment-17108053 ] Enrico Olivelli commented on CALCITE-3997: -- [~hyuan] I confirm that on current master in Calcite the test is now passing ! great work > Problem with MERGE JOIN: java.lang.AssertionError: cannot merge join: left > input is not sorted on left keys > --- > > Key: CALCITE-3997 > URL: https://issues.apache.org/jira/browse/CALCITE-3997 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.23.0 >Reporter: Enrico Olivelli >Priority: Blocker > Fix For: 1.23.0 > > Time Spent: 2h 10m > Remaining Estimate: 0h > > I have a couple of problems with HerdDB. > 1) JOIN order unsorted columns in presence of a WHERE over other columns > This is my case: > CREATE TABLE tblspace1.table1 (k1 string primary key,n1 int,s1 string) > CREATE TABLE tblspace1.table3 (k1 string primary key,n3 int,s3 string) > SELECT t1.k1 as first, t2.k1 as second > FROMtblspace1.table1 t1 > INNER JOIN tblspace1.table3 t2 ON t1.k1=t2.k1 > WHERE t1.n1 + 1 = t2.n3 > In this case for table1 and table3 no column is physically sorted (no column > with a collation) > I have this Planner error: > java.lang.AssertionError: cannot merge join: left input is not sorted on left > keys > at > org.apache.calcite.rel.metadata.RelMdCollation.mergeJoin(RelMdCollation.java:457) > at > org.apache.calcite.rel.metadata.RelMdCollation.collations(RelMdCollation.java:153) > at GeneratedMetadataHandler_Collation.collations_$(Unknown Source) > at GeneratedMetadataHandler_Collation.collations(Unknown Source) > at > org.apache.calcite.rel.metadata.RelMetadataQuery.collations(RelMetadataQuery.java:539) > at > org.apache.calcite.rel.metadata.RelMdCollation.project(RelMdCollation.java:273) > at > org.apache.calcite.rel.logical.LogicalProject.lambda$create$0(LogicalProject.java:122) > at org.apache.calcite.plan.RelTraitSet.replaceIfs(RelTraitSet.java:242) > at > org.apache.calcite.rel.logical.LogicalProject.create(LogicalProject.java:121) > at > org.apache.calcite.rel.logical.LogicalProject.create(LogicalProject.java:111) > at > org.apache.calcite.rel.core.RelFactories$ProjectFactoryImpl.createProject(RelFactories.java:172) > at org.apache.calcite.tools.RelBuilder.project_(RelBuilder.java:1464) > at org.apache.calcite.tools.RelBuilder.project(RelBuilder.java:1258) > at org.apache.calcite.tools.RelBuilder.project(RelBuilder.java:1230) > at org.apache.calcite.tools.RelBuilder.project(RelBuilder.java:1219) > at > org.apache.calcite.plan.RelOptUtil.pushDownJoinConditions(RelOptUtil.java:3620) > at > org.apache.calcite.rel.rules.JoinPushExpressionsRule.onMatch(JoinPushExpressionsRule.java:59) > at > org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:221) > at > org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:519) > at herddb.sql.CalcitePlanner.runPlanner(CalcitePlanner.java:535) > at herddb.sql.CalcitePlanner.translate(CalcitePlanner.java:292) > If I remove the "WHERE" clause then no error is reported. > we have many other test cases about JOINs and this one is the only one that > fails > This is the failing test case on HerdDB > https://github.com/diennea/herddb/blob/vote-calcite-123/herddb-core/src/test/java/herddb/core/SimpleJoinTest.java#L522 > We are using the default set of rules Programs.ofRules(Programs.RULE_SET) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3997) Problem with MERGE JOIN: java.lang.AssertionError: cannot merge join: left input is not sorted on left keys
[ https://issues.apache.org/jira/browse/CALCITE-3997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17107610#comment-17107610 ] Enrico Olivelli commented on CALCITE-3997: -- Thank you. I will check tomorrow if this patch fixed my issue > Problem with MERGE JOIN: java.lang.AssertionError: cannot merge join: left > input is not sorted on left keys > --- > > Key: CALCITE-3997 > URL: https://issues.apache.org/jira/browse/CALCITE-3997 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.23.0 >Reporter: Enrico Olivelli >Priority: Blocker > Fix For: 1.23.0 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > I have a couple of problems with HerdDB. > 1) JOIN order unsorted columns in presence of a WHERE over other columns > This is my case: > CREATE TABLE tblspace1.table1 (k1 string primary key,n1 int,s1 string) > CREATE TABLE tblspace1.table3 (k1 string primary key,n3 int,s3 string) > SELECT t1.k1 as first, t2.k1 as second > FROMtblspace1.table1 t1 > INNER JOIN tblspace1.table3 t2 ON t1.k1=t2.k1 > WHERE t1.n1 + 1 = t2.n3 > In this case for table1 and table3 no column is physically sorted (no column > with a collation) > I have this Planner error: > java.lang.AssertionError: cannot merge join: left input is not sorted on left > keys > at > org.apache.calcite.rel.metadata.RelMdCollation.mergeJoin(RelMdCollation.java:457) > at > org.apache.calcite.rel.metadata.RelMdCollation.collations(RelMdCollation.java:153) > at GeneratedMetadataHandler_Collation.collations_$(Unknown Source) > at GeneratedMetadataHandler_Collation.collations(Unknown Source) > at > org.apache.calcite.rel.metadata.RelMetadataQuery.collations(RelMetadataQuery.java:539) > at > org.apache.calcite.rel.metadata.RelMdCollation.project(RelMdCollation.java:273) > at > org.apache.calcite.rel.logical.LogicalProject.lambda$create$0(LogicalProject.java:122) > at org.apache.calcite.plan.RelTraitSet.replaceIfs(RelTraitSet.java:242) > at > org.apache.calcite.rel.logical.LogicalProject.create(LogicalProject.java:121) > at > org.apache.calcite.rel.logical.LogicalProject.create(LogicalProject.java:111) > at > org.apache.calcite.rel.core.RelFactories$ProjectFactoryImpl.createProject(RelFactories.java:172) > at org.apache.calcite.tools.RelBuilder.project_(RelBuilder.java:1464) > at org.apache.calcite.tools.RelBuilder.project(RelBuilder.java:1258) > at org.apache.calcite.tools.RelBuilder.project(RelBuilder.java:1230) > at org.apache.calcite.tools.RelBuilder.project(RelBuilder.java:1219) > at > org.apache.calcite.plan.RelOptUtil.pushDownJoinConditions(RelOptUtil.java:3620) > at > org.apache.calcite.rel.rules.JoinPushExpressionsRule.onMatch(JoinPushExpressionsRule.java:59) > at > org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:221) > at > org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:519) > at herddb.sql.CalcitePlanner.runPlanner(CalcitePlanner.java:535) > at herddb.sql.CalcitePlanner.translate(CalcitePlanner.java:292) > If I remove the "WHERE" clause then no error is reported. > we have many other test cases about JOINs and this one is the only one that > fails > This is the failing test case on HerdDB > https://github.com/diennea/herddb/blob/vote-calcite-123/herddb-core/src/test/java/herddb/core/SimpleJoinTest.java#L522 > We are using the default set of rules Programs.ofRules(Programs.RULE_SET) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3997) Problem with MERGE JOIN: java.lang.AssertionError: cannot merge join: left input is not sorted on left keys
[ https://issues.apache.org/jira/browse/CALCITE-3997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17107260#comment-17107260 ] Enrico Olivelli commented on CALCITE-3997: -- [~hyuan] I have removed that rules https://github.com/diennea/herddb/pull/599/files#diff-ca87d7835fc281efa58a8809669017a9R506 but the test is not passing anyway [~winipanda] would you have time to help with this other problem with HerdDB vs Calcite 1.23 ? > Problem with MERGE JOIN: java.lang.AssertionError: cannot merge join: left > input is not sorted on left keys > --- > > Key: CALCITE-3997 > URL: https://issues.apache.org/jira/browse/CALCITE-3997 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.23.0 >Reporter: Enrico Olivelli >Priority: Blocker > > I have a couple of problems with HerdDB. > 1) JOIN order unsorted columns in presence of a WHERE over other columns > This is my case: > CREATE TABLE tblspace1.table1 (k1 string primary key,n1 int,s1 string) > CREATE TABLE tblspace1.table3 (k1 string primary key,n3 int,s3 string) > SELECT t1.k1 as first, t2.k1 as second > FROMtblspace1.table1 t1 > INNER JOIN tblspace1.table3 t2 ON t1.k1=t2.k1 > WHERE t1.n1 + 1 = t2.n3 > In this case for table1 and table3 no column is physically sorted (no column > with a collation) > I have this Planner error: > java.lang.AssertionError: cannot merge join: left input is not sorted on left > keys > at > org.apache.calcite.rel.metadata.RelMdCollation.mergeJoin(RelMdCollation.java:457) > at > org.apache.calcite.rel.metadata.RelMdCollation.collations(RelMdCollation.java:153) > at GeneratedMetadataHandler_Collation.collations_$(Unknown Source) > at GeneratedMetadataHandler_Collation.collations(Unknown Source) > at > org.apache.calcite.rel.metadata.RelMetadataQuery.collations(RelMetadataQuery.java:539) > at > org.apache.calcite.rel.metadata.RelMdCollation.project(RelMdCollation.java:273) > at > org.apache.calcite.rel.logical.LogicalProject.lambda$create$0(LogicalProject.java:122) > at org.apache.calcite.plan.RelTraitSet.replaceIfs(RelTraitSet.java:242) > at > org.apache.calcite.rel.logical.LogicalProject.create(LogicalProject.java:121) > at > org.apache.calcite.rel.logical.LogicalProject.create(LogicalProject.java:111) > at > org.apache.calcite.rel.core.RelFactories$ProjectFactoryImpl.createProject(RelFactories.java:172) > at org.apache.calcite.tools.RelBuilder.project_(RelBuilder.java:1464) > at org.apache.calcite.tools.RelBuilder.project(RelBuilder.java:1258) > at org.apache.calcite.tools.RelBuilder.project(RelBuilder.java:1230) > at org.apache.calcite.tools.RelBuilder.project(RelBuilder.java:1219) > at > org.apache.calcite.plan.RelOptUtil.pushDownJoinConditions(RelOptUtil.java:3620) > at > org.apache.calcite.rel.rules.JoinPushExpressionsRule.onMatch(JoinPushExpressionsRule.java:59) > at > org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:221) > at > org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:519) > at herddb.sql.CalcitePlanner.runPlanner(CalcitePlanner.java:535) > at herddb.sql.CalcitePlanner.translate(CalcitePlanner.java:292) > If I remove the "WHERE" clause then no error is reported. > we have many other test cases about JOINs and this one is the only one that > fails > This is the failing test case on HerdDB > https://github.com/diennea/herddb/blob/vote-calcite-123/herddb-core/src/test/java/herddb/core/SimpleJoinTest.java#L522 > We are using the default set of rules Programs.ofRules(Programs.RULE_SET) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-3997) Problem with MERGE JOIN: java.lang.AssertionError: cannot merge join: left input is not sorted on left keys
[ https://issues.apache.org/jira/browse/CALCITE-3997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17107260#comment-17107260 ] Enrico Olivelli edited comment on CALCITE-3997 at 5/14/20, 12:34 PM: - [~hyuan] I have removed that rule https://github.com/diennea/herddb/pull/599/files#diff-ca87d7835fc281efa58a8809669017a9R506 but the test is not passing anyway [~winipanda] would you have time to help with this other problem with HerdDB vs Calcite 1.23 ? was (Author: eolivelli): [~hyuan] I have removed that rules https://github.com/diennea/herddb/pull/599/files#diff-ca87d7835fc281efa58a8809669017a9R506 but the test is not passing anyway [~winipanda] would you have time to help with this other problem with HerdDB vs Calcite 1.23 ? > Problem with MERGE JOIN: java.lang.AssertionError: cannot merge join: left > input is not sorted on left keys > --- > > Key: CALCITE-3997 > URL: https://issues.apache.org/jira/browse/CALCITE-3997 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.23.0 >Reporter: Enrico Olivelli >Priority: Blocker > > I have a couple of problems with HerdDB. > 1) JOIN order unsorted columns in presence of a WHERE over other columns > This is my case: > CREATE TABLE tblspace1.table1 (k1 string primary key,n1 int,s1 string) > CREATE TABLE tblspace1.table3 (k1 string primary key,n3 int,s3 string) > SELECT t1.k1 as first, t2.k1 as second > FROMtblspace1.table1 t1 > INNER JOIN tblspace1.table3 t2 ON t1.k1=t2.k1 > WHERE t1.n1 + 1 = t2.n3 > In this case for table1 and table3 no column is physically sorted (no column > with a collation) > I have this Planner error: > java.lang.AssertionError: cannot merge join: left input is not sorted on left > keys > at > org.apache.calcite.rel.metadata.RelMdCollation.mergeJoin(RelMdCollation.java:457) > at > org.apache.calcite.rel.metadata.RelMdCollation.collations(RelMdCollation.java:153) > at GeneratedMetadataHandler_Collation.collations_$(Unknown Source) > at GeneratedMetadataHandler_Collation.collations(Unknown Source) > at > org.apache.calcite.rel.metadata.RelMetadataQuery.collations(RelMetadataQuery.java:539) > at > org.apache.calcite.rel.metadata.RelMdCollation.project(RelMdCollation.java:273) > at > org.apache.calcite.rel.logical.LogicalProject.lambda$create$0(LogicalProject.java:122) > at org.apache.calcite.plan.RelTraitSet.replaceIfs(RelTraitSet.java:242) > at > org.apache.calcite.rel.logical.LogicalProject.create(LogicalProject.java:121) > at > org.apache.calcite.rel.logical.LogicalProject.create(LogicalProject.java:111) > at > org.apache.calcite.rel.core.RelFactories$ProjectFactoryImpl.createProject(RelFactories.java:172) > at org.apache.calcite.tools.RelBuilder.project_(RelBuilder.java:1464) > at org.apache.calcite.tools.RelBuilder.project(RelBuilder.java:1258) > at org.apache.calcite.tools.RelBuilder.project(RelBuilder.java:1230) > at org.apache.calcite.tools.RelBuilder.project(RelBuilder.java:1219) > at > org.apache.calcite.plan.RelOptUtil.pushDownJoinConditions(RelOptUtil.java:3620) > at > org.apache.calcite.rel.rules.JoinPushExpressionsRule.onMatch(JoinPushExpressionsRule.java:59) > at > org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:221) > at > org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:519) > at herddb.sql.CalcitePlanner.runPlanner(CalcitePlanner.java:535) > at herddb.sql.CalcitePlanner.translate(CalcitePlanner.java:292) > If I remove the "WHERE" clause then no error is reported. > we have many other test cases about JOINs and this one is the only one that > fails > This is the failing test case on HerdDB > https://github.com/diennea/herddb/blob/vote-calcite-123/herddb-core/src/test/java/herddb/core/SimpleJoinTest.java#L522 > We are using the default set of rules Programs.ofRules(Programs.RULE_SET) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CALCITE-3998) Bad datatype for sum(n), it should be BIGINT but it is sometimes INTEGER
[
https://issues.apache.org/jira/browse/CALCITE-3998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Enrico Olivelli resolved CALCITE-3998.
--
Resolution: Not A Problem
> Bad datatype for sum(n), it should be BIGINT but it is sometimes INTEGER
>
>
> Key: CALCITE-3998
> URL: https://issues.apache.org/jira/browse/CALCITE-3998
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.23.0
>Reporter: Enrico Olivelli
>Priority: Blocker
> Attachments: image-2020-05-14-15-37-14-571.png,
> image-2020-05-14-15-39-28-279.png, image-2020-05-14-16-15-59-907.png,
> image-2020-05-14-17-07-49-157.png, image-2020-05-14-17-12-11-277.png
>
>
> I also noted that sometimes the type of sum(N) where N is an INTEGER column
> sometimes it is now reported by Calcite as INTEGER and sometimes as a BIGINT.
> In 1.22 every time is reported as BIGINT.
> So we have another test failing.
> SELECT sum(n1), count(*) as cc, k1
> FROM tblspace1.tsql
> GROUP by k1
> ORDER BY sum(n1)
> Here sum(n1) is reported now a INTEGER, previously it was a BIGINT. I would
> prefer to see it as a BIGINT in order to prevent overflows
> Here are the plans:
> {noformat}
> INFO: Query: SELECT sum(n1), count(*) as cc, k1 FROM tblspace1.tsql GROUP by
> k1 ORDER BY sum(n1) -- Logical Plan
> LogicalSort(sort0=[$0], dir0=[ASC]): rowcount = 2.0, cumulative cost =
> {10.52595367432 rows, 37.0 cpu, 0.0 io}, id = 1038
> LogicalProject(EXPR$0=[$1], CC=[$2], K1=[$0]): rowcount = 2.0, cumulative
> cost = {8.52595367432 rows, 13.0 cpu, 0.0 io}, id = 1037
> LogicalAggregate(group=[{0}], EXPR$0=[SUM($1)], CC=[COUNT()]): rowcount =
> 2.0, cumulative cost = {6.52595367432 rows, 7.0 cpu, 0.0 io}, id = 1035
> LogicalProject(K1=[$0], n1=[$1]): rowcount = 2.0, cumulative cost =
> {4.0 rows, 7.0 cpu, 0.0 io}, id = 1034
> LogicalTableScan(table=[[tblspace1, tsql]]): rowcount = 2.0,
> cumulative cost = {2.0 rows, 3.0 cpu, 0.0 io}, id = 1032
> May 12, 2020 11:07:37 AM herddb.sql.CalcitePlanner runPlanner
> INFO: Query: SELECT sum(n1), count(*) as cc, k1 FROM tblspace1.tsql GROUP by
> k1 ORDER BY sum(n1) -- Best Plan
> EnumerableSort(sort0=[$0], dir0=[ASC]): rowcount = 2.0, cumulative cost =
> {5.0 rows, 31.0 cpu, 0.0 io}, id = 1245
> EnumerableProject(EXPR$0=[$1], CC=[1:BIGINT], K1=[$0]): rowcount = 2.0,
> cumulative cost = {3.0 rows, 7.0 cpu, 0.0 io}, id = 1244
> EnumerableInterpreter: rowcount = 2.0, cumulative cost = {1.0 rows, 1.0
> cpu, 0.0 io}, id = 1243
> BindableTableScan(table=[[tblspace1, tsql]], projects=[[0, 1]]):
> rowcount = 2.0, cumulative cost = {0.016 rows, 0.024 cpu, 0.0 io}, id = 1055
> {noformat}
> Within the same test case with the same tables the result of this query is
> not changed
> SELECT sum(n1) as ss, min(n1) as mi, max(n1) as ma FROM tblspace1.tsql
> INFO: Query: SELECT sum(n1) as ss, min(n1) as mi, max(n1) as ma FROM
> tblspace1.tsql -- Logical Plan
> {noformat}
> LogicalAggregate(group=[{}], SS=[SUM($0)], MI=[MIN($0)], MA=[MAX($0)]):
> rowcount = 1.0, cumulative cost = {5.387500047683716 rows, 5.0 cpu, 0.0 io},
> id = 1253
> LogicalProject(n1=[$1]): rowcount = 2.0, cumulative cost = {4.0 rows, 5.0
> cpu, 0.0 io}, id = 1252
> LogicalTableScan(table=[[tblspace1, tsql]]): rowcount = 2.0, cumulative
> cost = {2.0 rows, 3.0 cpu, 0.0 io}, id = 1250
> May 12, 2020 11:08:48 AM herddb.sql.CalcitePlanner runPlanner
> INFO: Query: SELECT sum(n1) as ss, min(n1) as mi, max(n1) as ma FROM
> tblspace1.tsql -- Best Plan
> EnumerableAggregate(group=[{}], SS=[SUM($0)], MI=[MIN($0)], MA=[MAX($0)]):
> rowcount = 1.0, cumulative cost = {2.387500047683716 rows, 1.0 cpu, 0.0 io},
> id = 1295
> EnumerableInterpreter: rowcount = 2.0, cumulative cost = {1.0 rows, 1.0
> cpu, 0.0 io}, id = 1294
> BindableTableScan(table=[[tblspace1, tsql]], projects=[[1]]): rowcount =
> 2.0, cumulative cost = {0.012 rows, 0.018002 cpu, 0.0 io}, id =
> 1265
> {noformat}
> This is the test on HerdDB
> https://github.com/diennea/herddb/blob/vote-calcite-123/herddb-core/src/test/java/herddb/sql/SimplerPlannerTest.java#L237
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3998) Bad datatype for sum(n), it should be BIGINT but it is sometimes INTEGER
[
https://issues.apache.org/jira/browse/CALCITE-3998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17107254#comment-17107254
]
Enrico Olivelli commented on CALCITE-3998:
--
In this case Calcite looks very smart !
As K1 is the PK sum(n1) will aggregate only one an thus there is no risk of
integer overflow.
As a counter example if I create the table without a PK
{code:java}
CREATE TABLE tblspace1.tsql (k1 string ,n1 int,s1 string)
{code}
instead of
{code:java}
CREATE TABLE tblspace1.tsql (k1 string PRIMARY KEY ,n1 int,s1 string)
{code}
the data type is now BIGINT as before.
So we can close this issue as "not a problem"
It demonstrates that Calcite 1.23 is smarter than 1.22 !!
thank you [~winipanda] for your time in this issue
> Bad datatype for sum(n), it should be BIGINT but it is sometimes INTEGER
>
>
> Key: CALCITE-3998
> URL: https://issues.apache.org/jira/browse/CALCITE-3998
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.23.0
>Reporter: Enrico Olivelli
>Priority: Blocker
> Attachments: image-2020-05-14-15-37-14-571.png,
> image-2020-05-14-15-39-28-279.png, image-2020-05-14-16-15-59-907.png,
> image-2020-05-14-17-07-49-157.png, image-2020-05-14-17-12-11-277.png
>
>
> I also noted that sometimes the type of sum(N) where N is an INTEGER column
> sometimes it is now reported by Calcite as INTEGER and sometimes as a BIGINT.
> In 1.22 every time is reported as BIGINT.
> So we have another test failing.
> SELECT sum(n1), count(*) as cc, k1
> FROM tblspace1.tsql
> GROUP by k1
> ORDER BY sum(n1)
> Here sum(n1) is reported now a INTEGER, previously it was a BIGINT. I would
> prefer to see it as a BIGINT in order to prevent overflows
> Here are the plans:
> {noformat}
> INFO: Query: SELECT sum(n1), count(*) as cc, k1 FROM tblspace1.tsql GROUP by
> k1 ORDER BY sum(n1) -- Logical Plan
> LogicalSort(sort0=[$0], dir0=[ASC]): rowcount = 2.0, cumulative cost =
> {10.52595367432 rows, 37.0 cpu, 0.0 io}, id = 1038
> LogicalProject(EXPR$0=[$1], CC=[$2], K1=[$0]): rowcount = 2.0, cumulative
> cost = {8.52595367432 rows, 13.0 cpu, 0.0 io}, id = 1037
> LogicalAggregate(group=[{0}], EXPR$0=[SUM($1)], CC=[COUNT()]): rowcount =
> 2.0, cumulative cost = {6.52595367432 rows, 7.0 cpu, 0.0 io}, id = 1035
> LogicalProject(K1=[$0], n1=[$1]): rowcount = 2.0, cumulative cost =
> {4.0 rows, 7.0 cpu, 0.0 io}, id = 1034
> LogicalTableScan(table=[[tblspace1, tsql]]): rowcount = 2.0,
> cumulative cost = {2.0 rows, 3.0 cpu, 0.0 io}, id = 1032
> May 12, 2020 11:07:37 AM herddb.sql.CalcitePlanner runPlanner
> INFO: Query: SELECT sum(n1), count(*) as cc, k1 FROM tblspace1.tsql GROUP by
> k1 ORDER BY sum(n1) -- Best Plan
> EnumerableSort(sort0=[$0], dir0=[ASC]): rowcount = 2.0, cumulative cost =
> {5.0 rows, 31.0 cpu, 0.0 io}, id = 1245
> EnumerableProject(EXPR$0=[$1], CC=[1:BIGINT], K1=[$0]): rowcount = 2.0,
> cumulative cost = {3.0 rows, 7.0 cpu, 0.0 io}, id = 1244
> EnumerableInterpreter: rowcount = 2.0, cumulative cost = {1.0 rows, 1.0
> cpu, 0.0 io}, id = 1243
> BindableTableScan(table=[[tblspace1, tsql]], projects=[[0, 1]]):
> rowcount = 2.0, cumulative cost = {0.016 rows, 0.024 cpu, 0.0 io}, id = 1055
> {noformat}
> Within the same test case with the same tables the result of this query is
> not changed
> SELECT sum(n1) as ss, min(n1) as mi, max(n1) as ma FROM tblspace1.tsql
> INFO: Query: SELECT sum(n1) as ss, min(n1) as mi, max(n1) as ma FROM
> tblspace1.tsql -- Logical Plan
> {noformat}
> LogicalAggregate(group=[{}], SS=[SUM($0)], MI=[MIN($0)], MA=[MAX($0)]):
> rowcount = 1.0, cumulative cost = {5.387500047683716 rows, 5.0 cpu, 0.0 io},
> id = 1253
> LogicalProject(n1=[$1]): rowcount = 2.0, cumulative cost = {4.0 rows, 5.0
> cpu, 0.0 io}, id = 1252
> LogicalTableScan(table=[[tblspace1, tsql]]): rowcount = 2.0, cumulative
> cost = {2.0 rows, 3.0 cpu, 0.0 io}, id = 1250
> May 12, 2020 11:08:48 AM herddb.sql.CalcitePlanner runPlanner
> INFO: Query: SELECT sum(n1) as ss, min(n1) as mi, max(n1) as ma FROM
> tblspace1.tsql -- Best Plan
> EnumerableAggregate(group=[{}], SS=[SUM($0)], MI=[MIN($0)], MA=[MAX($0)]):
> rowcount = 1.0, cumulative cost = {2.387500047683716 rows, 1.0 cpu, 0.0 io},
> id = 1295
> EnumerableInterpreter: rowcount = 2.0, cumulative cost = {1.0 rows, 1.0
> cpu, 0.0 io}, id = 1294
> BindableTableScan(table=[[tblspace1, tsql]], projects=[[1]]): rowcount =
> 2.0, cumulative cost = {0.012 rows, 0.018002 cpu, 0.0 io}, id =
> 1265
> {noformat}
> This is the test on HerdDB
> https://github.com/diennea/herddb/blob/vote-calcite-123/herddb-core/src/test/java/herddb/sql/SimplerPlannerTest.java#L237
--
This message was sent by Atlassian Jira
[jira] [Commented] (CALCITE-3998) Bad datatype for sum(n), it should be BIGINT but it is sometimes INTEGER
[
https://issues.apache.org/jira/browse/CALCITE-3998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17107167#comment-17107167
]
Enrico Olivelli commented on CALCITE-3998:
--
[~winipanda]
I have run the tests adding "-Dherddb.planner.dumpqueryloglevel=INFO" system
property,
this way CalcitePlanner dumps the plans
with 1.23 I see this plan
{noformat}
INFORMAZIONI: Query: SELECT sum(n1), count(*) as cc, k1 FROM tblspace1.tsql
GROUP by k1 ORDER BY sum(n1) -- Logical Plan
LogicalSort(sort0=[$0], dir0=[ASC]): rowcount = 2.0, cumulative cost =
{10.52595367432 rows, 37.0 cpu, 0.0 io}, id = 35
LogicalProject(EXPR$0=[$1], CC=[$2], K1=[$0]): rowcount = 2.0, cumulative
cost = {8.52595367432 rows, 13.0 cpu, 0.0 io}, id = 34
LogicalAggregate(group=[{0}], EXPR$0=[SUM($1)], CC=[COUNT()]): rowcount =
2.0, cumulative cost = {6.52595367432 rows, 7.0 cpu, 0.0 io}, id = 32
LogicalProject(K1=[$0], n1=[$1]): rowcount = 2.0, cumulative cost = {4.0
rows, 7.0 cpu, 0.0 io}, id = 31
LogicalTableScan(table=[[tblspace1, tsql]]): rowcount = 2.0, cumulative
cost = {2.0 rows, 3.0 cpu, 0.0 io}, id = 29
mag 14, 2020 11:57:47 AM herddb.sql.CalcitePlanner runPlanner
INFORMAZIONI: Query: SELECT sum(n1), count(*) as cc, k1 FROM tblspace1.tsql
GROUP by k1 ORDER BY sum(n1) -- Best Plan
EnumerableSort(sort0=[$0], dir0=[ASC]): rowcount = 2.0, cumulative cost = {5.0
rows, 31.0 cpu, 0.0 io}, id = 242
EnumerableProject(EXPR$0=[$1], CC=[1:BIGINT], K1=[$0]): rowcount = 2.0,
cumulative cost = {3.0 rows, 7.0 cpu, 0.0 io}, id = 241
EnumerableInterpreter: rowcount = 2.0, cumulative cost = {1.0 rows, 1.0
cpu, 0.0 io}, id = 240
BindableTableScan(table=[[tblspace1, tsql]], projects=[[0, 1]]): rowcount
= 2.0, cumulative cost = {0.016 rows, 0.024 cpu, 0.0 io}, id = 52
{noformat}
with 1.22 I see this plan
{code:java}
INFORMAZIONI: Query: SELECT sum(n1), count(*) as cc, k1 FROM tblspace1.tsql
GROUP by k1 ORDER BY sum(n1) -- Logical Plan
LogicalSort(sort0=[$0], dir0=[ASC]): rowcount = 2.0, cumulative cost =
{10.52595367432 rows, 37.0 cpu, 0.0 io}, id = 34
LogicalProject(EXPR$0=[$1], CC=[$2], K1=[$0]): rowcount = 2.0, cumulative
cost = {8.52595367432 rows, 13.0 cpu, 0.0 io}, id = 33
LogicalAggregate(group=[{0}], EXPR$0=[SUM($1)], CC=[COUNT()]): rowcount =
2.0, cumulative cost = {6.52595367432 rows, 7.0 cpu, 0.0 io}, id = 31
LogicalProject(K1=[$0], n1=[$1]): rowcount = 2.0, cumulative cost = {4.0
rows, 7.0 cpu, 0.0 io}, id = 30
LogicalTableScan(table=[[tblspace1, tsql]]): rowcount = 2.0, cumulative
cost = {2.0 rows, 3.0 cpu, 0.0 io}, id = 28
mag 14, 2020 11:58:52 AM herddb.sql.CalcitePlanner runPlanner
INFORMAZIONI: Query: SELECT sum(n1), count(*) as cc, k1 FROM tblspace1.tsql
GROUP by k1 ORDER BY sum(n1) -- Best Plan
EnumerableProject(EXPR$0=[$1], CC=[$2], K1=[$0]): rowcount = 1.0, cumulative
cost = {4.262500047683716 rows, 16.0 cpu, 0.0 io}, id = 274
EnumerableSort(sort0=[$1], dir0=[ASC]): rowcount = 1.0, cumulative cost =
{3.262500047683716 rows, 13.0 cpu, 0.0 io}, id = 273
EnumerableAggregate(group=[{0}], EXPR$0=[SUM($1)], CC=[COUNT()]): rowcount
= 1.0, cumulative cost = {2.262500047683716 rows, 1.0 cpu, 0.0 io}, id = 272
EnumerableInterpreter: rowcount = 2.0, cumulative cost = {1.0 rows, 1.0
cpu, 0.0 io}, id = 271
BindableTableScan(table=[[tblspace1, tsql]], projects=[[0, 1]]):
rowcount = 2.0, cumulative cost = {0.016 rows, 0.024 cpu, 0.0 io}, id = 69
{code}
in 1.22 we have a EnumerableAggregate that it is not present in 1.23
I hope that helps
> Bad datatype for sum(n), it should be BIGINT but it is sometimes INTEGER
>
>
> Key: CALCITE-3998
> URL: https://issues.apache.org/jira/browse/CALCITE-3998
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.23.0
>Reporter: Enrico Olivelli
>Priority: Blocker
> Attachments: image-2020-05-14-15-37-14-571.png,
> image-2020-05-14-15-39-28-279.png, image-2020-05-14-16-15-59-907.png,
> image-2020-05-14-17-07-49-157.png, image-2020-05-14-17-12-11-277.png
>
>
> I also noted that sometimes the type of sum(N) where N is an INTEGER column
> sometimes it is now reported by Calcite as INTEGER and sometimes as a BIGINT.
> In 1.22 every time is reported as BIGINT.
> So we have another test failing.
> SELECT sum(n1), count(*) as cc, k1
> FROM tblspace1.tsql
> GROUP by k1
> ORDER BY sum(n1)
> Here sum(n1) is reported now a INTEGER, previously it was a BIGINT. I would
> prefer to see it as a BIGINT in order to prevent overflows
> Here are the plans:
> {noformat}
> INFO: Query: SELECT sum(n1), count(*) as cc, k1 FROM tblspace1.tsql GROUP by
> k1 ORDER BY sum(n1) -- Logical Plan
> LogicalSort(sort0=[$0], dir0=[ASC]):
[jira] [Commented] (CALCITE-3998) Bad datatype for sum(n), it should be BIGINT but it is sometimes INTEGER
[
https://issues.apache.org/jira/browse/CALCITE-3998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17107159#comment-17107159
]
Enrico Olivelli commented on CALCITE-3998:
--
[~winipanda]
the only difference between master branch and vote-calcite-123 branch is on the
pom
see
https://github.com/diennea/herddb/pull/599/files
SumColumnCalcultor was not changed
> Bad datatype for sum(n), it should be BIGINT but it is sometimes INTEGER
>
>
> Key: CALCITE-3998
> URL: https://issues.apache.org/jira/browse/CALCITE-3998
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.23.0
>Reporter: Enrico Olivelli
>Priority: Blocker
> Attachments: image-2020-05-14-15-37-14-571.png,
> image-2020-05-14-15-39-28-279.png, image-2020-05-14-16-15-59-907.png,
> image-2020-05-14-17-07-49-157.png, image-2020-05-14-17-12-11-277.png
>
>
> I also noted that sometimes the type of sum(N) where N is an INTEGER column
> sometimes it is now reported by Calcite as INTEGER and sometimes as a BIGINT.
> In 1.22 every time is reported as BIGINT.
> So we have another test failing.
> SELECT sum(n1), count(*) as cc, k1
> FROM tblspace1.tsql
> GROUP by k1
> ORDER BY sum(n1)
> Here sum(n1) is reported now a INTEGER, previously it was a BIGINT. I would
> prefer to see it as a BIGINT in order to prevent overflows
> Here are the plans:
> {noformat}
> INFO: Query: SELECT sum(n1), count(*) as cc, k1 FROM tblspace1.tsql GROUP by
> k1 ORDER BY sum(n1) -- Logical Plan
> LogicalSort(sort0=[$0], dir0=[ASC]): rowcount = 2.0, cumulative cost =
> {10.52595367432 rows, 37.0 cpu, 0.0 io}, id = 1038
> LogicalProject(EXPR$0=[$1], CC=[$2], K1=[$0]): rowcount = 2.0, cumulative
> cost = {8.52595367432 rows, 13.0 cpu, 0.0 io}, id = 1037
> LogicalAggregate(group=[{0}], EXPR$0=[SUM($1)], CC=[COUNT()]): rowcount =
> 2.0, cumulative cost = {6.52595367432 rows, 7.0 cpu, 0.0 io}, id = 1035
> LogicalProject(K1=[$0], n1=[$1]): rowcount = 2.0, cumulative cost =
> {4.0 rows, 7.0 cpu, 0.0 io}, id = 1034
> LogicalTableScan(table=[[tblspace1, tsql]]): rowcount = 2.0,
> cumulative cost = {2.0 rows, 3.0 cpu, 0.0 io}, id = 1032
> May 12, 2020 11:07:37 AM herddb.sql.CalcitePlanner runPlanner
> INFO: Query: SELECT sum(n1), count(*) as cc, k1 FROM tblspace1.tsql GROUP by
> k1 ORDER BY sum(n1) -- Best Plan
> EnumerableSort(sort0=[$0], dir0=[ASC]): rowcount = 2.0, cumulative cost =
> {5.0 rows, 31.0 cpu, 0.0 io}, id = 1245
> EnumerableProject(EXPR$0=[$1], CC=[1:BIGINT], K1=[$0]): rowcount = 2.0,
> cumulative cost = {3.0 rows, 7.0 cpu, 0.0 io}, id = 1244
> EnumerableInterpreter: rowcount = 2.0, cumulative cost = {1.0 rows, 1.0
> cpu, 0.0 io}, id = 1243
> BindableTableScan(table=[[tblspace1, tsql]], projects=[[0, 1]]):
> rowcount = 2.0, cumulative cost = {0.016 rows, 0.024 cpu, 0.0 io}, id = 1055
> {noformat}
> Within the same test case with the same tables the result of this query is
> not changed
> SELECT sum(n1) as ss, min(n1) as mi, max(n1) as ma FROM tblspace1.tsql
> INFO: Query: SELECT sum(n1) as ss, min(n1) as mi, max(n1) as ma FROM
> tblspace1.tsql -- Logical Plan
> {noformat}
> LogicalAggregate(group=[{}], SS=[SUM($0)], MI=[MIN($0)], MA=[MAX($0)]):
> rowcount = 1.0, cumulative cost = {5.387500047683716 rows, 5.0 cpu, 0.0 io},
> id = 1253
> LogicalProject(n1=[$1]): rowcount = 2.0, cumulative cost = {4.0 rows, 5.0
> cpu, 0.0 io}, id = 1252
> LogicalTableScan(table=[[tblspace1, tsql]]): rowcount = 2.0, cumulative
> cost = {2.0 rows, 3.0 cpu, 0.0 io}, id = 1250
> May 12, 2020 11:08:48 AM herddb.sql.CalcitePlanner runPlanner
> INFO: Query: SELECT sum(n1) as ss, min(n1) as mi, max(n1) as ma FROM
> tblspace1.tsql -- Best Plan
> EnumerableAggregate(group=[{}], SS=[SUM($0)], MI=[MIN($0)], MA=[MAX($0)]):
> rowcount = 1.0, cumulative cost = {2.387500047683716 rows, 1.0 cpu, 0.0 io},
> id = 1295
> EnumerableInterpreter: rowcount = 2.0, cumulative cost = {1.0 rows, 1.0
> cpu, 0.0 io}, id = 1294
> BindableTableScan(table=[[tblspace1, tsql]], projects=[[1]]): rowcount =
> 2.0, cumulative cost = {0.012 rows, 0.018002 cpu, 0.0 io}, id =
> 1265
> {noformat}
> This is the test on HerdDB
> https://github.com/diennea/herddb/blob/vote-calcite-123/herddb-core/src/test/java/herddb/sql/SimplerPlannerTest.java#L237
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-3998) Bad datatype for sum(n), it should be BIGINT but it is sometimes INTEGER
[
https://issues.apache.org/jira/browse/CALCITE-3998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17107141#comment-17107141
]
Enrico Olivelli edited comment on CALCITE-3998 at 5/14/20, 9:37 AM:
[~winipanda] thank you for debugging.
Do you see differences between master and the branch with Calcite 1.23 ?
in my calcite branch 1.23 the code of HerdDB is the same as it is on master
branch, changing only calcite version
I am very sorry but today I am super busy at work and I cannot debug
was (Author: eolivelli):
[~winipanda] thank you for debugging.
Do you see differences between master and the branch with Calcite 1.23 ?
in my calcite branch 1.23 the code of HerdDB is the same as it is on master
branch, changing only calcite version
> Bad datatype for sum(n), it should be BIGINT but it is sometimes INTEGER
>
>
> Key: CALCITE-3998
> URL: https://issues.apache.org/jira/browse/CALCITE-3998
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.23.0
>Reporter: Enrico Olivelli
>Priority: Blocker
> Attachments: image-2020-05-14-15-37-14-571.png,
> image-2020-05-14-15-39-28-279.png, image-2020-05-14-16-15-59-907.png,
> image-2020-05-14-17-07-49-157.png, image-2020-05-14-17-12-11-277.png
>
>
> I also noted that sometimes the type of sum(N) where N is an INTEGER column
> sometimes it is now reported by Calcite as INTEGER and sometimes as a BIGINT.
> In 1.22 every time is reported as BIGINT.
> So we have another test failing.
> SELECT sum(n1), count(*) as cc, k1
> FROM tblspace1.tsql
> GROUP by k1
> ORDER BY sum(n1)
> Here sum(n1) is reported now a INTEGER, previously it was a BIGINT. I would
> prefer to see it as a BIGINT in order to prevent overflows
> Here are the plans:
> {noformat}
> INFO: Query: SELECT sum(n1), count(*) as cc, k1 FROM tblspace1.tsql GROUP by
> k1 ORDER BY sum(n1) -- Logical Plan
> LogicalSort(sort0=[$0], dir0=[ASC]): rowcount = 2.0, cumulative cost =
> {10.52595367432 rows, 37.0 cpu, 0.0 io}, id = 1038
> LogicalProject(EXPR$0=[$1], CC=[$2], K1=[$0]): rowcount = 2.0, cumulative
> cost = {8.52595367432 rows, 13.0 cpu, 0.0 io}, id = 1037
> LogicalAggregate(group=[{0}], EXPR$0=[SUM($1)], CC=[COUNT()]): rowcount =
> 2.0, cumulative cost = {6.52595367432 rows, 7.0 cpu, 0.0 io}, id = 1035
> LogicalProject(K1=[$0], n1=[$1]): rowcount = 2.0, cumulative cost =
> {4.0 rows, 7.0 cpu, 0.0 io}, id = 1034
> LogicalTableScan(table=[[tblspace1, tsql]]): rowcount = 2.0,
> cumulative cost = {2.0 rows, 3.0 cpu, 0.0 io}, id = 1032
> May 12, 2020 11:07:37 AM herddb.sql.CalcitePlanner runPlanner
> INFO: Query: SELECT sum(n1), count(*) as cc, k1 FROM tblspace1.tsql GROUP by
> k1 ORDER BY sum(n1) -- Best Plan
> EnumerableSort(sort0=[$0], dir0=[ASC]): rowcount = 2.0, cumulative cost =
> {5.0 rows, 31.0 cpu, 0.0 io}, id = 1245
> EnumerableProject(EXPR$0=[$1], CC=[1:BIGINT], K1=[$0]): rowcount = 2.0,
> cumulative cost = {3.0 rows, 7.0 cpu, 0.0 io}, id = 1244
> EnumerableInterpreter: rowcount = 2.0, cumulative cost = {1.0 rows, 1.0
> cpu, 0.0 io}, id = 1243
> BindableTableScan(table=[[tblspace1, tsql]], projects=[[0, 1]]):
> rowcount = 2.0, cumulative cost = {0.016 rows, 0.024 cpu, 0.0 io}, id = 1055
> {noformat}
> Within the same test case with the same tables the result of this query is
> not changed
> SELECT sum(n1) as ss, min(n1) as mi, max(n1) as ma FROM tblspace1.tsql
> INFO: Query: SELECT sum(n1) as ss, min(n1) as mi, max(n1) as ma FROM
> tblspace1.tsql -- Logical Plan
> {noformat}
> LogicalAggregate(group=[{}], SS=[SUM($0)], MI=[MIN($0)], MA=[MAX($0)]):
> rowcount = 1.0, cumulative cost = {5.387500047683716 rows, 5.0 cpu, 0.0 io},
> id = 1253
> LogicalProject(n1=[$1]): rowcount = 2.0, cumulative cost = {4.0 rows, 5.0
> cpu, 0.0 io}, id = 1252
> LogicalTableScan(table=[[tblspace1, tsql]]): rowcount = 2.0, cumulative
> cost = {2.0 rows, 3.0 cpu, 0.0 io}, id = 1250
> May 12, 2020 11:08:48 AM herddb.sql.CalcitePlanner runPlanner
> INFO: Query: SELECT sum(n1) as ss, min(n1) as mi, max(n1) as ma FROM
> tblspace1.tsql -- Best Plan
> EnumerableAggregate(group=[{}], SS=[SUM($0)], MI=[MIN($0)], MA=[MAX($0)]):
> rowcount = 1.0, cumulative cost = {2.387500047683716 rows, 1.0 cpu, 0.0 io},
> id = 1295
> EnumerableInterpreter: rowcount = 2.0, cumulative cost = {1.0 rows, 1.0
> cpu, 0.0 io}, id = 1294
> BindableTableScan(table=[[tblspace1, tsql]], projects=[[1]]): rowcount =
> 2.0, cumulative cost = {0.012 rows, 0.018002 cpu, 0.0 io}, id =
> 1265
> {noformat}
> This is the test on HerdDB
> https://github.com/diennea/herddb/blob/vote-calcite-123/herddb-core/src/test/java/herddb/sql/SimplerPlannerTest.java#L237
--
This message was
[jira] [Commented] (CALCITE-3998) Bad datatype for sum(n), it should be BIGINT but it is sometimes INTEGER
[
https://issues.apache.org/jira/browse/CALCITE-3998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17107141#comment-17107141
]
Enrico Olivelli commented on CALCITE-3998:
--
[~winipanda] thank you for debugging.
Do you see differences between master and the branch with Calcite 1.23 ?
in my calcite branch 1.23 the code of HerdDB is the same as it is on master
branch, changing only calcite version
> Bad datatype for sum(n), it should be BIGINT but it is sometimes INTEGER
>
>
> Key: CALCITE-3998
> URL: https://issues.apache.org/jira/browse/CALCITE-3998
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.23.0
>Reporter: Enrico Olivelli
>Priority: Blocker
> Attachments: image-2020-05-14-15-37-14-571.png,
> image-2020-05-14-15-39-28-279.png, image-2020-05-14-16-15-59-907.png,
> image-2020-05-14-17-07-49-157.png, image-2020-05-14-17-12-11-277.png
>
>
> I also noted that sometimes the type of sum(N) where N is an INTEGER column
> sometimes it is now reported by Calcite as INTEGER and sometimes as a BIGINT.
> In 1.22 every time is reported as BIGINT.
> So we have another test failing.
> SELECT sum(n1), count(*) as cc, k1
> FROM tblspace1.tsql
> GROUP by k1
> ORDER BY sum(n1)
> Here sum(n1) is reported now a INTEGER, previously it was a BIGINT. I would
> prefer to see it as a BIGINT in order to prevent overflows
> Here are the plans:
> {noformat}
> INFO: Query: SELECT sum(n1), count(*) as cc, k1 FROM tblspace1.tsql GROUP by
> k1 ORDER BY sum(n1) -- Logical Plan
> LogicalSort(sort0=[$0], dir0=[ASC]): rowcount = 2.0, cumulative cost =
> {10.52595367432 rows, 37.0 cpu, 0.0 io}, id = 1038
> LogicalProject(EXPR$0=[$1], CC=[$2], K1=[$0]): rowcount = 2.0, cumulative
> cost = {8.52595367432 rows, 13.0 cpu, 0.0 io}, id = 1037
> LogicalAggregate(group=[{0}], EXPR$0=[SUM($1)], CC=[COUNT()]): rowcount =
> 2.0, cumulative cost = {6.52595367432 rows, 7.0 cpu, 0.0 io}, id = 1035
> LogicalProject(K1=[$0], n1=[$1]): rowcount = 2.0, cumulative cost =
> {4.0 rows, 7.0 cpu, 0.0 io}, id = 1034
> LogicalTableScan(table=[[tblspace1, tsql]]): rowcount = 2.0,
> cumulative cost = {2.0 rows, 3.0 cpu, 0.0 io}, id = 1032
> May 12, 2020 11:07:37 AM herddb.sql.CalcitePlanner runPlanner
> INFO: Query: SELECT sum(n1), count(*) as cc, k1 FROM tblspace1.tsql GROUP by
> k1 ORDER BY sum(n1) -- Best Plan
> EnumerableSort(sort0=[$0], dir0=[ASC]): rowcount = 2.0, cumulative cost =
> {5.0 rows, 31.0 cpu, 0.0 io}, id = 1245
> EnumerableProject(EXPR$0=[$1], CC=[1:BIGINT], K1=[$0]): rowcount = 2.0,
> cumulative cost = {3.0 rows, 7.0 cpu, 0.0 io}, id = 1244
> EnumerableInterpreter: rowcount = 2.0, cumulative cost = {1.0 rows, 1.0
> cpu, 0.0 io}, id = 1243
> BindableTableScan(table=[[tblspace1, tsql]], projects=[[0, 1]]):
> rowcount = 2.0, cumulative cost = {0.016 rows, 0.024 cpu, 0.0 io}, id = 1055
> {noformat}
> Within the same test case with the same tables the result of this query is
> not changed
> SELECT sum(n1) as ss, min(n1) as mi, max(n1) as ma FROM tblspace1.tsql
> INFO: Query: SELECT sum(n1) as ss, min(n1) as mi, max(n1) as ma FROM
> tblspace1.tsql -- Logical Plan
> {noformat}
> LogicalAggregate(group=[{}], SS=[SUM($0)], MI=[MIN($0)], MA=[MAX($0)]):
> rowcount = 1.0, cumulative cost = {5.387500047683716 rows, 5.0 cpu, 0.0 io},
> id = 1253
> LogicalProject(n1=[$1]): rowcount = 2.0, cumulative cost = {4.0 rows, 5.0
> cpu, 0.0 io}, id = 1252
> LogicalTableScan(table=[[tblspace1, tsql]]): rowcount = 2.0, cumulative
> cost = {2.0 rows, 3.0 cpu, 0.0 io}, id = 1250
> May 12, 2020 11:08:48 AM herddb.sql.CalcitePlanner runPlanner
> INFO: Query: SELECT sum(n1) as ss, min(n1) as mi, max(n1) as ma FROM
> tblspace1.tsql -- Best Plan
> EnumerableAggregate(group=[{}], SS=[SUM($0)], MI=[MIN($0)], MA=[MAX($0)]):
> rowcount = 1.0, cumulative cost = {2.387500047683716 rows, 1.0 cpu, 0.0 io},
> id = 1295
> EnumerableInterpreter: rowcount = 2.0, cumulative cost = {1.0 rows, 1.0
> cpu, 0.0 io}, id = 1294
> BindableTableScan(table=[[tblspace1, tsql]], projects=[[1]]): rowcount =
> 2.0, cumulative cost = {0.012 rows, 0.018002 cpu, 0.0 io}, id =
> 1265
> {noformat}
> This is the test on HerdDB
> https://github.com/diennea/herddb/blob/vote-calcite-123/herddb-core/src/test/java/herddb/sql/SimplerPlannerTest.java#L237
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3998) Bad datatype for sum(n), it should be BIGINT but it is sometimes INTEGER
[
https://issues.apache.org/jira/browse/CALCITE-3998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17107062#comment-17107062
]
Enrico Olivelli commented on CALCITE-3998:
--
{quote}
I'm curious. why the return type of "sum(n1)" is Bigint when n1 is integer, How
does it do that? Does this change occurs in Calcite or in HerdDB?
{quote}
It should be in Calcite.
I think it is because of possible overflow.
> Bad datatype for sum(n), it should be BIGINT but it is sometimes INTEGER
>
>
> Key: CALCITE-3998
> URL: https://issues.apache.org/jira/browse/CALCITE-3998
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.23.0
>Reporter: Enrico Olivelli
>Priority: Blocker
> Attachments: image-2020-05-14-15-37-14-571.png,
> image-2020-05-14-15-39-28-279.png, image-2020-05-14-16-15-59-907.png
>
>
> I also noted that sometimes the type of sum(N) where N is an INTEGER column
> sometimes it is now reported by Calcite as INTEGER and sometimes as a BIGINT.
> In 1.22 every time is reported as BIGINT.
> So we have another test failing.
> SELECT sum(n1), count(*) as cc, k1
> FROM tblspace1.tsql
> GROUP by k1
> ORDER BY sum(n1)
> Here sum(n1) is reported now a INTEGER, previously it was a BIGINT. I would
> prefer to see it as a BIGINT in order to prevent overflows
> Here are the plans:
> {noformat}
> INFO: Query: SELECT sum(n1), count(*) as cc, k1 FROM tblspace1.tsql GROUP by
> k1 ORDER BY sum(n1) -- Logical Plan
> LogicalSort(sort0=[$0], dir0=[ASC]): rowcount = 2.0, cumulative cost =
> {10.52595367432 rows, 37.0 cpu, 0.0 io}, id = 1038
> LogicalProject(EXPR$0=[$1], CC=[$2], K1=[$0]): rowcount = 2.0, cumulative
> cost = {8.52595367432 rows, 13.0 cpu, 0.0 io}, id = 1037
> LogicalAggregate(group=[{0}], EXPR$0=[SUM($1)], CC=[COUNT()]): rowcount =
> 2.0, cumulative cost = {6.52595367432 rows, 7.0 cpu, 0.0 io}, id = 1035
> LogicalProject(K1=[$0], n1=[$1]): rowcount = 2.0, cumulative cost =
> {4.0 rows, 7.0 cpu, 0.0 io}, id = 1034
> LogicalTableScan(table=[[tblspace1, tsql]]): rowcount = 2.0,
> cumulative cost = {2.0 rows, 3.0 cpu, 0.0 io}, id = 1032
> May 12, 2020 11:07:37 AM herddb.sql.CalcitePlanner runPlanner
> INFO: Query: SELECT sum(n1), count(*) as cc, k1 FROM tblspace1.tsql GROUP by
> k1 ORDER BY sum(n1) -- Best Plan
> EnumerableSort(sort0=[$0], dir0=[ASC]): rowcount = 2.0, cumulative cost =
> {5.0 rows, 31.0 cpu, 0.0 io}, id = 1245
> EnumerableProject(EXPR$0=[$1], CC=[1:BIGINT], K1=[$0]): rowcount = 2.0,
> cumulative cost = {3.0 rows, 7.0 cpu, 0.0 io}, id = 1244
> EnumerableInterpreter: rowcount = 2.0, cumulative cost = {1.0 rows, 1.0
> cpu, 0.0 io}, id = 1243
> BindableTableScan(table=[[tblspace1, tsql]], projects=[[0, 1]]):
> rowcount = 2.0, cumulative cost = {0.016 rows, 0.024 cpu, 0.0 io}, id = 1055
> {noformat}
> Within the same test case with the same tables the result of this query is
> not changed
> SELECT sum(n1) as ss, min(n1) as mi, max(n1) as ma FROM tblspace1.tsql
> INFO: Query: SELECT sum(n1) as ss, min(n1) as mi, max(n1) as ma FROM
> tblspace1.tsql -- Logical Plan
> {noformat}
> LogicalAggregate(group=[{}], SS=[SUM($0)], MI=[MIN($0)], MA=[MAX($0)]):
> rowcount = 1.0, cumulative cost = {5.387500047683716 rows, 5.0 cpu, 0.0 io},
> id = 1253
> LogicalProject(n1=[$1]): rowcount = 2.0, cumulative cost = {4.0 rows, 5.0
> cpu, 0.0 io}, id = 1252
> LogicalTableScan(table=[[tblspace1, tsql]]): rowcount = 2.0, cumulative
> cost = {2.0 rows, 3.0 cpu, 0.0 io}, id = 1250
> May 12, 2020 11:08:48 AM herddb.sql.CalcitePlanner runPlanner
> INFO: Query: SELECT sum(n1) as ss, min(n1) as mi, max(n1) as ma FROM
> tblspace1.tsql -- Best Plan
> EnumerableAggregate(group=[{}], SS=[SUM($0)], MI=[MIN($0)], MA=[MAX($0)]):
> rowcount = 1.0, cumulative cost = {2.387500047683716 rows, 1.0 cpu, 0.0 io},
> id = 1295
> EnumerableInterpreter: rowcount = 2.0, cumulative cost = {1.0 rows, 1.0
> cpu, 0.0 io}, id = 1294
> BindableTableScan(table=[[tblspace1, tsql]], projects=[[1]]): rowcount =
> 2.0, cumulative cost = {0.012 rows, 0.018002 cpu, 0.0 io}, id =
> 1265
> {noformat}
> This is the test on HerdDB
> https://github.com/diennea/herddb/blob/vote-calcite-123/herddb-core/src/test/java/herddb/sql/SimplerPlannerTest.java#L237
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3998) Bad datatype for sum(n), it should be BIGINT but it is sometimes INTEGER
[
https://issues.apache.org/jira/browse/CALCITE-3998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17107032#comment-17107032
]
Enrico Olivelli commented on CALCITE-3998:
--
The test is failing here
https://github.com/diennea/herddb/blob/vote-calcite-123/herddb-core/src/test/java/herddb/sql/SimplerPlannerTest.java#L245
with Calcite 1.22 the result is a java.lang.Long, that is mapped to BIGINT on
Calcite.
query is:
{noformat}
SELECT sum(n1), count(*) as cc, k1
FROM tblspace1.tsql
GROUP by k1
ORDER BY sum(n1)
{noformat}
at line
https://github.com/diennea/herddb/blob/vote-calcite-123/herddb-core/src/test/java/herddb/sql/SimplerPlannerTest.java#L245
the result of sum is java.lang.Long
query is:
{noformat}
SELECT sum(n1) as ss, min(n1) as mi, max(n1) as ma
FROM tblspace1.tsql
{noformat}
I found this interesting, at line:
https://github.com/diennea/herddb/blob/vote-calcite-123/herddb-core/src/test/java/herddb/sql/SimplerPlannerTest.java#L275
the result of sum is Integer
{noformat}
SELECT sum(n1), count(*) as cc, k1
FROM tblspace1.tsql
GROUP by k1
HAVING sum(n1) <= 1234
{noformat}
> Bad datatype for sum(n), it should be BIGINT but it is sometimes INTEGER
>
>
> Key: CALCITE-3998
> URL: https://issues.apache.org/jira/browse/CALCITE-3998
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.23.0
>Reporter: Enrico Olivelli
>Priority: Blocker
> Attachments: image-2020-05-14-15-37-14-571.png,
> image-2020-05-14-15-39-28-279.png
>
>
> I also noted that sometimes the type of sum(N) where N is an INTEGER column
> sometimes it is now reported by Calcite as INTEGER and sometimes as a BIGINT.
> In 1.22 every time is reported as BIGINT.
> So we have another test failing.
> SELECT sum(n1), count(*) as cc, k1
> FROM tblspace1.tsql
> GROUP by k1
> ORDER BY sum(n1)
> Here sum(n1) is reported now a INTEGER, previously it was a BIGINT. I would
> prefer to see it as a BIGINT in order to prevent overflows
> Here are the plans:
> {noformat}
> INFO: Query: SELECT sum(n1), count(*) as cc, k1 FROM tblspace1.tsql GROUP by
> k1 ORDER BY sum(n1) -- Logical Plan
> LogicalSort(sort0=[$0], dir0=[ASC]): rowcount = 2.0, cumulative cost =
> {10.52595367432 rows, 37.0 cpu, 0.0 io}, id = 1038
> LogicalProject(EXPR$0=[$1], CC=[$2], K1=[$0]): rowcount = 2.0, cumulative
> cost = {8.52595367432 rows, 13.0 cpu, 0.0 io}, id = 1037
> LogicalAggregate(group=[{0}], EXPR$0=[SUM($1)], CC=[COUNT()]): rowcount =
> 2.0, cumulative cost = {6.52595367432 rows, 7.0 cpu, 0.0 io}, id = 1035
> LogicalProject(K1=[$0], n1=[$1]): rowcount = 2.0, cumulative cost =
> {4.0 rows, 7.0 cpu, 0.0 io}, id = 1034
> LogicalTableScan(table=[[tblspace1, tsql]]): rowcount = 2.0,
> cumulative cost = {2.0 rows, 3.0 cpu, 0.0 io}, id = 1032
> May 12, 2020 11:07:37 AM herddb.sql.CalcitePlanner runPlanner
> INFO: Query: SELECT sum(n1), count(*) as cc, k1 FROM tblspace1.tsql GROUP by
> k1 ORDER BY sum(n1) -- Best Plan
> EnumerableSort(sort0=[$0], dir0=[ASC]): rowcount = 2.0, cumulative cost =
> {5.0 rows, 31.0 cpu, 0.0 io}, id = 1245
> EnumerableProject(EXPR$0=[$1], CC=[1:BIGINT], K1=[$0]): rowcount = 2.0,
> cumulative cost = {3.0 rows, 7.0 cpu, 0.0 io}, id = 1244
> EnumerableInterpreter: rowcount = 2.0, cumulative cost = {1.0 rows, 1.0
> cpu, 0.0 io}, id = 1243
> BindableTableScan(table=[[tblspace1, tsql]], projects=[[0, 1]]):
> rowcount = 2.0, cumulative cost = {0.016 rows, 0.024 cpu, 0.0 io}, id = 1055
> {noformat}
> Within the same test case with the same tables the result of this query is
> not changed
> SELECT sum(n1) as ss, min(n1) as mi, max(n1) as ma FROM tblspace1.tsql
> INFO: Query: SELECT sum(n1) as ss, min(n1) as mi, max(n1) as ma FROM
> tblspace1.tsql -- Logical Plan
> {noformat}
> LogicalAggregate(group=[{}], SS=[SUM($0)], MI=[MIN($0)], MA=[MAX($0)]):
> rowcount = 1.0, cumulative cost = {5.387500047683716 rows, 5.0 cpu, 0.0 io},
> id = 1253
> LogicalProject(n1=[$1]): rowcount = 2.0, cumulative cost = {4.0 rows, 5.0
> cpu, 0.0 io}, id = 1252
> LogicalTableScan(table=[[tblspace1, tsql]]): rowcount = 2.0, cumulative
> cost = {2.0 rows, 3.0 cpu, 0.0 io}, id = 1250
> May 12, 2020 11:08:48 AM herddb.sql.CalcitePlanner runPlanner
> INFO: Query: SELECT sum(n1) as ss, min(n1) as mi, max(n1) as ma FROM
> tblspace1.tsql -- Best Plan
> EnumerableAggregate(group=[{}], SS=[SUM($0)], MI=[MIN($0)], MA=[MAX($0)]):
> rowcount = 1.0, cumulative cost = {2.387500047683716 rows, 1.0 cpu, 0.0 io},
> id = 1295
> EnumerableInterpreter: rowcount = 2.0, cumulative cost = {1.0 rows, 1.0
> cpu, 0.0 io}, id = 1294
> BindableTableScan(table=[[tblspace1, tsql]], projects=[[1]]): rowcount =
> 2.0, cumulative cost = {0.012 rows, 0.018002
[jira] [Commented] (CALCITE-3998) Bad datatype for sum(n), it should be BIGINT but it is sometimes INTEGER
[
https://issues.apache.org/jira/browse/CALCITE-3998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17107029#comment-17107029
]
Enrico Olivelli commented on CALCITE-3998:
--
[~winipanda] thank you so much
In the pom.xml we have 1.23
https://github.com/diennea/herddb/blob/vote-calcite-123/pom.xml#L92
in fact the test is not failing on master branch, that is using 1.22
> Bad datatype for sum(n), it should be BIGINT but it is sometimes INTEGER
>
>
> Key: CALCITE-3998
> URL: https://issues.apache.org/jira/browse/CALCITE-3998
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.23.0
>Reporter: Enrico Olivelli
>Priority: Blocker
> Attachments: image-2020-05-14-15-37-14-571.png,
> image-2020-05-14-15-39-28-279.png
>
>
> I also noted that sometimes the type of sum(N) where N is an INTEGER column
> sometimes it is now reported by Calcite as INTEGER and sometimes as a BIGINT.
> In 1.22 every time is reported as BIGINT.
> So we have another test failing.
> SELECT sum(n1), count(*) as cc, k1
> FROM tblspace1.tsql
> GROUP by k1
> ORDER BY sum(n1)
> Here sum(n1) is reported now a INTEGER, previously it was a BIGINT. I would
> prefer to see it as a BIGINT in order to prevent overflows
> Here are the plans:
> {noformat}
> INFO: Query: SELECT sum(n1), count(*) as cc, k1 FROM tblspace1.tsql GROUP by
> k1 ORDER BY sum(n1) -- Logical Plan
> LogicalSort(sort0=[$0], dir0=[ASC]): rowcount = 2.0, cumulative cost =
> {10.52595367432 rows, 37.0 cpu, 0.0 io}, id = 1038
> LogicalProject(EXPR$0=[$1], CC=[$2], K1=[$0]): rowcount = 2.0, cumulative
> cost = {8.52595367432 rows, 13.0 cpu, 0.0 io}, id = 1037
> LogicalAggregate(group=[{0}], EXPR$0=[SUM($1)], CC=[COUNT()]): rowcount =
> 2.0, cumulative cost = {6.52595367432 rows, 7.0 cpu, 0.0 io}, id = 1035
> LogicalProject(K1=[$0], n1=[$1]): rowcount = 2.0, cumulative cost =
> {4.0 rows, 7.0 cpu, 0.0 io}, id = 1034
> LogicalTableScan(table=[[tblspace1, tsql]]): rowcount = 2.0,
> cumulative cost = {2.0 rows, 3.0 cpu, 0.0 io}, id = 1032
> May 12, 2020 11:07:37 AM herddb.sql.CalcitePlanner runPlanner
> INFO: Query: SELECT sum(n1), count(*) as cc, k1 FROM tblspace1.tsql GROUP by
> k1 ORDER BY sum(n1) -- Best Plan
> EnumerableSort(sort0=[$0], dir0=[ASC]): rowcount = 2.0, cumulative cost =
> {5.0 rows, 31.0 cpu, 0.0 io}, id = 1245
> EnumerableProject(EXPR$0=[$1], CC=[1:BIGINT], K1=[$0]): rowcount = 2.0,
> cumulative cost = {3.0 rows, 7.0 cpu, 0.0 io}, id = 1244
> EnumerableInterpreter: rowcount = 2.0, cumulative cost = {1.0 rows, 1.0
> cpu, 0.0 io}, id = 1243
> BindableTableScan(table=[[tblspace1, tsql]], projects=[[0, 1]]):
> rowcount = 2.0, cumulative cost = {0.016 rows, 0.024 cpu, 0.0 io}, id = 1055
> {noformat}
> Within the same test case with the same tables the result of this query is
> not changed
> SELECT sum(n1) as ss, min(n1) as mi, max(n1) as ma FROM tblspace1.tsql
> INFO: Query: SELECT sum(n1) as ss, min(n1) as mi, max(n1) as ma FROM
> tblspace1.tsql -- Logical Plan
> {noformat}
> LogicalAggregate(group=[{}], SS=[SUM($0)], MI=[MIN($0)], MA=[MAX($0)]):
> rowcount = 1.0, cumulative cost = {5.387500047683716 rows, 5.0 cpu, 0.0 io},
> id = 1253
> LogicalProject(n1=[$1]): rowcount = 2.0, cumulative cost = {4.0 rows, 5.0
> cpu, 0.0 io}, id = 1252
> LogicalTableScan(table=[[tblspace1, tsql]]): rowcount = 2.0, cumulative
> cost = {2.0 rows, 3.0 cpu, 0.0 io}, id = 1250
> May 12, 2020 11:08:48 AM herddb.sql.CalcitePlanner runPlanner
> INFO: Query: SELECT sum(n1) as ss, min(n1) as mi, max(n1) as ma FROM
> tblspace1.tsql -- Best Plan
> EnumerableAggregate(group=[{}], SS=[SUM($0)], MI=[MIN($0)], MA=[MAX($0)]):
> rowcount = 1.0, cumulative cost = {2.387500047683716 rows, 1.0 cpu, 0.0 io},
> id = 1295
> EnumerableInterpreter: rowcount = 2.0, cumulative cost = {1.0 rows, 1.0
> cpu, 0.0 io}, id = 1294
> BindableTableScan(table=[[tblspace1, tsql]], projects=[[1]]): rowcount =
> 2.0, cumulative cost = {0.012 rows, 0.018002 cpu, 0.0 io}, id =
> 1265
> {noformat}
> This is the test on HerdDB
> https://github.com/diennea/herddb/blob/vote-calcite-123/herddb-core/src/test/java/herddb/sql/SimplerPlannerTest.java#L237
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3998) Bad datatype for sum(n), it should be BIGINT but it is sometimes INTEGER
[
https://issues.apache.org/jira/browse/CALCITE-3998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Enrico Olivelli updated CALCITE-3998:
-
Description:
I also noted that sometimes the type of sum(N) where N is an INTEGER column
sometimes it is now reported by Calcite as INTEGER and sometimes as a BIGINT.
In 1.22 every time is reported as BIGINT.
So we have another test failing.
SELECT sum(n1), count(*) as cc, k1
FROM tblspace1.tsql
GROUP by k1
ORDER BY sum(n1)
Here sum(n1) is reported now a INTEGER, previously it was a BIGINT. I would
prefer to see it as a BIGINT in order to prevent overflows
Here are the plans:
{noformat}
INFO: Query: SELECT sum(n1), count(*) as cc, k1 FROM tblspace1.tsql GROUP by
k1 ORDER BY sum(n1) -- Logical Plan
LogicalSort(sort0=[$0], dir0=[ASC]): rowcount = 2.0, cumulative cost =
{10.52595367432 rows, 37.0 cpu, 0.0 io}, id = 1038
LogicalProject(EXPR$0=[$1], CC=[$2], K1=[$0]): rowcount = 2.0, cumulative
cost = {8.52595367432 rows, 13.0 cpu, 0.0 io}, id = 1037
LogicalAggregate(group=[{0}], EXPR$0=[SUM($1)], CC=[COUNT()]): rowcount =
2.0, cumulative cost = {6.52595367432 rows, 7.0 cpu, 0.0 io}, id = 1035
LogicalProject(K1=[$0], n1=[$1]): rowcount = 2.0, cumulative cost = {4.0
rows, 7.0 cpu, 0.0 io}, id = 1034
LogicalTableScan(table=[[tblspace1, tsql]]): rowcount = 2.0, cumulative
cost = {2.0 rows, 3.0 cpu, 0.0 io}, id = 1032
May 12, 2020 11:07:37 AM herddb.sql.CalcitePlanner runPlanner
INFO: Query: SELECT sum(n1), count(*) as cc, k1 FROM tblspace1.tsql GROUP by
k1 ORDER BY sum(n1) -- Best Plan
EnumerableSort(sort0=[$0], dir0=[ASC]): rowcount = 2.0, cumulative cost = {5.0
rows, 31.0 cpu, 0.0 io}, id = 1245
EnumerableProject(EXPR$0=[$1], CC=[1:BIGINT], K1=[$0]): rowcount = 2.0,
cumulative cost = {3.0 rows, 7.0 cpu, 0.0 io}, id = 1244
EnumerableInterpreter: rowcount = 2.0, cumulative cost = {1.0 rows, 1.0
cpu, 0.0 io}, id = 1243
BindableTableScan(table=[[tblspace1, tsql]], projects=[[0, 1]]): rowcount
= 2.0, cumulative cost = {0.016 rows, 0.024 cpu, 0.0 io}, id = 1055
{noformat}
Within the same test case with the same tables the result of this query is not
changed
SELECT sum(n1) as ss, min(n1) as mi, max(n1) as ma FROM tblspace1.tsql
INFO: Query: SELECT sum(n1) as ss, min(n1) as mi, max(n1) as ma FROM
tblspace1.tsql -- Logical Plan
{noformat}
LogicalAggregate(group=[{}], SS=[SUM($0)], MI=[MIN($0)], MA=[MAX($0)]):
rowcount = 1.0, cumulative cost = {5.387500047683716 rows, 5.0 cpu, 0.0 io}, id
= 1253
LogicalProject(n1=[$1]): rowcount = 2.0, cumulative cost = {4.0 rows, 5.0
cpu, 0.0 io}, id = 1252
LogicalTableScan(table=[[tblspace1, tsql]]): rowcount = 2.0, cumulative
cost = {2.0 rows, 3.0 cpu, 0.0 io}, id = 1250
May 12, 2020 11:08:48 AM herddb.sql.CalcitePlanner runPlanner
INFO: Query: SELECT sum(n1) as ss, min(n1) as mi, max(n1) as ma FROM
tblspace1.tsql -- Best Plan
EnumerableAggregate(group=[{}], SS=[SUM($0)], MI=[MIN($0)], MA=[MAX($0)]):
rowcount = 1.0, cumulative cost = {2.387500047683716 rows, 1.0 cpu, 0.0 io}, id
= 1295
EnumerableInterpreter: rowcount = 2.0, cumulative cost = {1.0 rows, 1.0 cpu,
0.0 io}, id = 1294
BindableTableScan(table=[[tblspace1, tsql]], projects=[[1]]): rowcount =
2.0, cumulative cost = {0.012 rows, 0.018002 cpu, 0.0 io}, id = 1265
{noformat}
This is the test on HerdDB
https://github.com/diennea/herddb/blob/vote-calcite-123/herddb-core/src/test/java/herddb/sql/SimplerPlannerTest.java#L237
was:
I also noted that sometimes the type of sum(N) where N is an INTEGER column
sometimes it is now reported by Calcite as INTEGER and sometimes as a BIGINT.
In 1.22 every time is reported as BIGINT.
So we have another test failing.
SELECT sum(n1), count(*) as cc, k1
FROM tblspace1.tsql
GROUP by k1
ORDER BY sum(n1)
Here sum(n1) is reported now a INTEGER, previously it was a BIGINT. I would
prefer to see it as a BIGINT in order to prevent overflows
Here are the plans:
INFO: Query: SELECT sum(n1), count(*) as cc, k1 FROM tblspace1.tsql GROUP by
k1 ORDER BY sum(n1) -- Logical Plan
LogicalSort(sort0=[$0], dir0=[ASC]): rowcount = 2.0, cumulative cost =
{10.52595367432 rows, 37.0 cpu, 0.0 io}, id = 1038
LogicalProject(EXPR$0=[$1], CC=[$2], K1=[$0]): rowcount = 2.0, cumulative
cost = {8.52595367432 rows, 13.0 cpu, 0.0 io}, id = 1037
LogicalAggregate(group=[{0}], EXPR$0=[SUM($1)], CC=[COUNT()]): rowcount =
2.0, cumulative cost = {6.52595367432 rows, 7.0 cpu, 0.0 io}, id = 1035
LogicalProject(K1=[$0], n1=[$1]): rowcount = 2.0, cumulative cost = {4.0
rows, 7.0 cpu, 0.0 io}, id = 1034
LogicalTableScan(table=[[tblspace1, tsql]]): rowcount = 2.0, cumulative
cost = {2.0 rows, 3.0 cpu, 0.0 io}, id = 1032
May 12, 2020 11:07:37 AM herddb.sql.CalcitePlanner runPlanner
INFO: Query: SELECT sum(n1), count(*) as cc, k1 FROM tblspace1.tsql GROUP by
k1 ORDER BY sum(n1) --
[jira] [Commented] (CALCITE-3997) Problem with MERGE JOIN: java.lang.AssertionError: cannot merge join: left input is not sorted on left keys
[ https://issues.apache.org/jira/browse/CALCITE-3997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17106372#comment-17106372 ] Enrico Olivelli commented on CALCITE-3997: -- can be issue related to CALCITE-3982 ? > Problem with MERGE JOIN: java.lang.AssertionError: cannot merge join: left > input is not sorted on left keys > --- > > Key: CALCITE-3997 > URL: https://issues.apache.org/jira/browse/CALCITE-3997 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.23.0 >Reporter: Enrico Olivelli >Priority: Blocker > > I have a couple of problems with HerdDB. > 1) JOIN order unsorted columns in presence of a WHERE over other columns > This is my case: > CREATE TABLE tblspace1.table1 (k1 string primary key,n1 int,s1 string) > CREATE TABLE tblspace1.table3 (k1 string primary key,n3 int,s3 string) > SELECT t1.k1 as first, t2.k1 as second > FROMtblspace1.table1 t1 > INNER JOIN tblspace1.table3 t2 ON t1.k1=t2.k1 > WHERE t1.n1 + 1 = t2.n3 > In this case for table1 and table3 no column is physically sorted (no column > with a collation) > I have this Planner error: > java.lang.AssertionError: cannot merge join: left input is not sorted on left > keys > at > org.apache.calcite.rel.metadata.RelMdCollation.mergeJoin(RelMdCollation.java:457) > at > org.apache.calcite.rel.metadata.RelMdCollation.collations(RelMdCollation.java:153) > at GeneratedMetadataHandler_Collation.collations_$(Unknown Source) > at GeneratedMetadataHandler_Collation.collations(Unknown Source) > at > org.apache.calcite.rel.metadata.RelMetadataQuery.collations(RelMetadataQuery.java:539) > at > org.apache.calcite.rel.metadata.RelMdCollation.project(RelMdCollation.java:273) > at > org.apache.calcite.rel.logical.LogicalProject.lambda$create$0(LogicalProject.java:122) > at org.apache.calcite.plan.RelTraitSet.replaceIfs(RelTraitSet.java:242) > at > org.apache.calcite.rel.logical.LogicalProject.create(LogicalProject.java:121) > at > org.apache.calcite.rel.logical.LogicalProject.create(LogicalProject.java:111) > at > org.apache.calcite.rel.core.RelFactories$ProjectFactoryImpl.createProject(RelFactories.java:172) > at org.apache.calcite.tools.RelBuilder.project_(RelBuilder.java:1464) > at org.apache.calcite.tools.RelBuilder.project(RelBuilder.java:1258) > at org.apache.calcite.tools.RelBuilder.project(RelBuilder.java:1230) > at org.apache.calcite.tools.RelBuilder.project(RelBuilder.java:1219) > at > org.apache.calcite.plan.RelOptUtil.pushDownJoinConditions(RelOptUtil.java:3620) > at > org.apache.calcite.rel.rules.JoinPushExpressionsRule.onMatch(JoinPushExpressionsRule.java:59) > at > org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:221) > at > org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:519) > at herddb.sql.CalcitePlanner.runPlanner(CalcitePlanner.java:535) > at herddb.sql.CalcitePlanner.translate(CalcitePlanner.java:292) > If I remove the "WHERE" clause then no error is reported. > we have many other test cases about JOINs and this one is the only one that > fails > This is the failing test case on HerdDB > https://github.com/diennea/herddb/blob/vote-calcite-123/herddb-core/src/test/java/herddb/core/SimpleJoinTest.java#L522 > We are using the default set of rules Programs.ofRules(Programs.RULE_SET) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-3998) Bad datatype for sum(n), it should be BIGINT but it is sometimes INTEGER
Enrico Olivelli created CALCITE-3998:
Summary: Bad datatype for sum(n), it should be BIGINT but it is
sometimes INTEGER
Key: CALCITE-3998
URL: https://issues.apache.org/jira/browse/CALCITE-3998
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.23.0
Reporter: Enrico Olivelli
I also noted that sometimes the type of sum(N) where N is an INTEGER column
sometimes it is now reported by Calcite as INTEGER and sometimes as a BIGINT.
In 1.22 every time is reported as BIGINT.
So we have another test failing.
SELECT sum(n1), count(*) as cc, k1
FROM tblspace1.tsql
GROUP by k1
ORDER BY sum(n1)
Here sum(n1) is reported now a INTEGER, previously it was a BIGINT. I would
prefer to see it as a BIGINT in order to prevent overflows
Here are the plans:
INFO: Query: SELECT sum(n1), count(*) as cc, k1 FROM tblspace1.tsql GROUP by
k1 ORDER BY sum(n1) -- Logical Plan
LogicalSort(sort0=[$0], dir0=[ASC]): rowcount = 2.0, cumulative cost =
{10.52595367432 rows, 37.0 cpu, 0.0 io}, id = 1038
LogicalProject(EXPR$0=[$1], CC=[$2], K1=[$0]): rowcount = 2.0, cumulative
cost = {8.52595367432 rows, 13.0 cpu, 0.0 io}, id = 1037
LogicalAggregate(group=[{0}], EXPR$0=[SUM($1)], CC=[COUNT()]): rowcount =
2.0, cumulative cost = {6.52595367432 rows, 7.0 cpu, 0.0 io}, id = 1035
LogicalProject(K1=[$0], n1=[$1]): rowcount = 2.0, cumulative cost = {4.0
rows, 7.0 cpu, 0.0 io}, id = 1034
LogicalTableScan(table=[[tblspace1, tsql]]): rowcount = 2.0, cumulative
cost = {2.0 rows, 3.0 cpu, 0.0 io}, id = 1032
May 12, 2020 11:07:37 AM herddb.sql.CalcitePlanner runPlanner
INFO: Query: SELECT sum(n1), count(*) as cc, k1 FROM tblspace1.tsql GROUP by
k1 ORDER BY sum(n1) -- Best Plan
EnumerableSort(sort0=[$0], dir0=[ASC]): rowcount = 2.0, cumulative cost = {5.0
rows, 31.0 cpu, 0.0 io}, id = 1245
EnumerableProject(EXPR$0=[$1], CC=[1:BIGINT], K1=[$0]): rowcount = 2.0,
cumulative cost = {3.0 rows, 7.0 cpu, 0.0 io}, id = 1244
EnumerableInterpreter: rowcount = 2.0, cumulative cost = {1.0 rows, 1.0
cpu, 0.0 io}, id = 1243
BindableTableScan(table=[[tblspace1, tsql]], projects=[[0, 1]]): rowcount
= 2.0, cumulative cost = {0.016 rows, 0.024 cpu, 0.0 io}, id = 1055
Within the same test case with the same tables the result of this query is not
changed
SELECT sum(n1) as ss, min(n1) as mi, max(n1) as ma FROM tblspace1.tsql
INFO: Query: SELECT sum(n1) as ss, min(n1) as mi, max(n1) as ma FROM
tblspace1.tsql -- Logical Plan
LogicalAggregate(group=[{}], SS=[SUM($0)], MI=[MIN($0)], MA=[MAX($0)]):
rowcount = 1.0, cumulative cost = {5.387500047683716 rows, 5.0 cpu, 0.0 io}, id
= 1253
LogicalProject(n1=[$1]): rowcount = 2.0, cumulative cost = {4.0 rows, 5.0
cpu, 0.0 io}, id = 1252
LogicalTableScan(table=[[tblspace1, tsql]]): rowcount = 2.0, cumulative
cost = {2.0 rows, 3.0 cpu, 0.0 io}, id = 1250
May 12, 2020 11:08:48 AM herddb.sql.CalcitePlanner runPlanner
INFO: Query: SELECT sum(n1) as ss, min(n1) as mi, max(n1) as ma FROM
tblspace1.tsql -- Best Plan
EnumerableAggregate(group=[{}], SS=[SUM($0)], MI=[MIN($0)], MA=[MAX($0)]):
rowcount = 1.0, cumulative cost = {2.387500047683716 rows, 1.0 cpu, 0.0 io}, id
= 1295
EnumerableInterpreter: rowcount = 2.0, cumulative cost = {1.0 rows, 1.0 cpu,
0.0 io}, id = 1294
BindableTableScan(table=[[tblspace1, tsql]], projects=[[1]]): rowcount =
2.0, cumulative cost = {0.012 rows, 0.018002 cpu, 0.0 io}, id = 1265
This is the test on HerdDB
https://github.com/diennea/herddb/blob/vote-calcite-123/herddb-core/src/test/java/herddb/sql/SimplerPlannerTest.java#L237
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-3997) Problem with MERGE JOIN: java.lang.AssertionError: cannot merge join: left input is not sorted on left keys
Enrico Olivelli created CALCITE-3997: Summary: Problem with MERGE JOIN: java.lang.AssertionError: cannot merge join: left input is not sorted on left keys Key: CALCITE-3997 URL: https://issues.apache.org/jira/browse/CALCITE-3997 Project: Calcite Issue Type: Bug Components: core Affects Versions: 1.23.0 Reporter: Enrico Olivelli I have a couple of problems with HerdDB. 1) JOIN order unsorted columns in presence of a WHERE over other columns This is my case: CREATE TABLE tblspace1.table1 (k1 string primary key,n1 int,s1 string) CREATE TABLE tblspace1.table3 (k1 string primary key,n3 int,s3 string) SELECT t1.k1 as first, t2.k1 as second FROMtblspace1.table1 t1 INNER JOIN tblspace1.table3 t2 ON t1.k1=t2.k1 WHERE t1.n1 + 1 = t2.n3 In this case for table1 and table3 no column is physically sorted (no column with a collation) I have this Planner error: java.lang.AssertionError: cannot merge join: left input is not sorted on left keys at org.apache.calcite.rel.metadata.RelMdCollation.mergeJoin(RelMdCollation.java:457) at org.apache.calcite.rel.metadata.RelMdCollation.collations(RelMdCollation.java:153) at GeneratedMetadataHandler_Collation.collations_$(Unknown Source) at GeneratedMetadataHandler_Collation.collations(Unknown Source) at org.apache.calcite.rel.metadata.RelMetadataQuery.collations(RelMetadataQuery.java:539) at org.apache.calcite.rel.metadata.RelMdCollation.project(RelMdCollation.java:273) at org.apache.calcite.rel.logical.LogicalProject.lambda$create$0(LogicalProject.java:122) at org.apache.calcite.plan.RelTraitSet.replaceIfs(RelTraitSet.java:242) at org.apache.calcite.rel.logical.LogicalProject.create(LogicalProject.java:121) at org.apache.calcite.rel.logical.LogicalProject.create(LogicalProject.java:111) at org.apache.calcite.rel.core.RelFactories$ProjectFactoryImpl.createProject(RelFactories.java:172) at org.apache.calcite.tools.RelBuilder.project_(RelBuilder.java:1464) at org.apache.calcite.tools.RelBuilder.project(RelBuilder.java:1258) at org.apache.calcite.tools.RelBuilder.project(RelBuilder.java:1230) at org.apache.calcite.tools.RelBuilder.project(RelBuilder.java:1219) at org.apache.calcite.plan.RelOptUtil.pushDownJoinConditions(RelOptUtil.java:3620) at org.apache.calcite.rel.rules.JoinPushExpressionsRule.onMatch(JoinPushExpressionsRule.java:59) at org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:221) at org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:519) at herddb.sql.CalcitePlanner.runPlanner(CalcitePlanner.java:535) at herddb.sql.CalcitePlanner.translate(CalcitePlanner.java:292) If I remove the "WHERE" clause then no error is reported. we have many other test cases about JOINs and this one is the only one that fails This is the failing test case on HerdDB https://github.com/diennea/herddb/blob/vote-calcite-123/herddb-core/src/test/java/herddb/core/SimpleJoinTest.java#L522 We are using the default set of rules Programs.ofRules(Programs.RULE_SET) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3826) UPDATE assigns wrong type to bind variables
[
https://issues.apache.org/jira/browse/CALCITE-3826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17046724#comment-17046724
]
Enrico Olivelli commented on CALCITE-3826:
--
Thank you [~zabetak] !
I hope there is any Calcite developer available for fixing this.
As long as I don't have a working env I can't.
Currently I am on other priorities and I can't spend much time in my dev env
> UPDATE assigns wrong type to bind variables
> ---
>
> Key: CALCITE-3826
> URL: https://issues.apache.org/jira/browse/CALCITE-3826
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.22.0
>Reporter: Enrico Olivelli
>Priority: Blocker
>
> In 1.22.0rc1 I have found a problem about
> EnumerableTableModify#getSourceExpressionList
> It looks like it is not mapping correctly the expected datatypes of
> bind variables in queries like UPDATE table set a=?,b=? where pk=?.
> You can see the full SQL here in this commit in my test branch here
> https://github.com/diennea/herddb/pull/563/commits/157f927c9efe85cf7cac1370e1637b1c7ec46dff#diff-5d7594bc81ae0c92bbd33dee6c0d189aR2301
> My case is the following:
> Create a table:
> CREATE TABLE t1 (
> field0 int PRIMARY KEY,
> field1 VARCHAR(10),
> field2 VARCHAR(10),
> field3 INT,
> field4 INT,
> field5 VARCHAR(10)
> )
> UPDATE t1 SET field3 =?, field2=?, field4=?, field5=? where field0=?
> The Update maps to this Calcite plan:
> EnumerableTableModify(table=[[tblspace1, ip]], operation=[UPDATE],
> updateColumnList=[[field3, field2, field4, field5]],
> sourceExpressionList=[[?0, ?1, ?2, ?3]], flattened=[true]): rowcount =
> 1.0, cumulative cost = {2.5 rows, 10.5 cpu, 0.0 io}, id = 62
> EnumerableProject(field0=[$0], field1=[$1], field2=[$2],
> field3=[$3], field4=[$4], field5=[$5], EXPR$0=[?0], EXPR$1=[?1],
> EXPR$2=[?2], EXPR$3=[?3]): rowcount = 1.0, cumulative cost = {1.5
> rows, 10.5 cpu, 0.0 io}, id = 61
> EnumerableInterpreter: rowcount = 1.0, cumulative cost = {0.5
> rows, 0.5 cpu, 0.0 io}, id = 60
> BindableTableScan(table=[[tblspace1, ip]], filters=[[=($0,
> ?4)]]): rowcount = 1.0, cumulative cost = {0.005 rows, 0.01 cpu, 0.0
> io}, id = 45
> In particular the obeserved problem is:
> - the updateColumnList field is: field3, field2, field4, field5
> - but the bind variables have wrong type: VARCHAR, VARCHAR, INT, INT,
> expecting INT VARCHAR, INT VARCHAR
> even by changing the UPDATE command the types of bind variables stays the
> same,
> and they are the in the same order as in the CREATE TABLE STATEMENT,
> skipping the PK.
> It may be a regression of CALCITE-3672
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3826) UPDATE assigns wrong type to bind variables
[
https://issues.apache.org/jira/browse/CALCITE-3826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17046647#comment-17046647
]
Enrico Olivelli commented on CALCITE-3826:
--
This is the simpler reproducer I have:
{code}
package test;
import com.google.common.collect.ImmutableList;
import java.lang.reflect.Type;
import java.util.Arrays;
import java.util.Collection;
import java.util.Collections;
import java.util.List;
import org.apache.calcite.DataContext;
import org.apache.calcite.avatica.util.Quoting;
import org.apache.calcite.linq4j.Enumerable;
import org.apache.calcite.linq4j.QueryProvider;
import org.apache.calcite.linq4j.Queryable;
import org.apache.calcite.linq4j.tree.Expression;
import org.apache.calcite.plan.ConventionTraitDef;
import org.apache.calcite.plan.RelOptCluster;
import org.apache.calcite.plan.RelOptTable;
import org.apache.calcite.plan.RelOptUtil;
import org.apache.calcite.plan.RelTraitDef;
import org.apache.calcite.prepare.Prepare;
import org.apache.calcite.rel.RelCollationTraitDef;
import org.apache.calcite.rel.RelNode;
import org.apache.calcite.rel.core.TableModify;
import org.apache.calcite.rel.logical.LogicalTableModify;
import org.apache.calcite.rel.type.RelDataType;
import org.apache.calcite.rel.type.RelDataTypeFactory;
import org.apache.calcite.rex.RexDynamicParam;
import org.apache.calcite.rex.RexNode;
import org.apache.calcite.schema.ModifiableTable;
import org.apache.calcite.schema.ProjectableFilterableTable;
import org.apache.calcite.schema.ScannableTable;
import org.apache.calcite.schema.SchemaPlus;
import org.apache.calcite.schema.Statistic;
import org.apache.calcite.schema.Statistics;
import org.apache.calcite.schema.impl.AbstractSchema;
import org.apache.calcite.schema.impl.AbstractTable;
import org.apache.calcite.sql.SqlExplainFormat;
import org.apache.calcite.sql.SqlExplainLevel;
import org.apache.calcite.sql.SqlNode;
import org.apache.calcite.sql.parser.SqlParser;
import org.apache.calcite.sql.type.SqlTypeName;
import org.apache.calcite.sql.validate.SqlConformanceEnum;
import org.apache.calcite.tools.FrameworkConfig;
import org.apache.calcite.tools.Frameworks;
import org.apache.calcite.tools.Planner;
import org.apache.calcite.tools.Programs;
import org.apache.calcite.util.ImmutableBitSet;
import static org.junit.jupiter.api.Assertions.assertEquals;
import org.junit.jupiter.api.Test;
public class UpdateTest {
private static final List TRAITS = Collections
.unmodifiableList(java.util.Arrays.asList(ConventionTraitDef.INSTANCE,
RelCollationTraitDef.INSTANCE));
private static final SqlParser.Config SQL_PARSER_CONFIG =
SqlParser.configBuilder(SqlParser.Config.DEFAULT)
.setCaseSensitive(false)
.setConformance(SqlConformanceEnum.MYSQL_5)
.setQuoting(Quoting.BACK_TICK)
.build();
@Test
public void hello() throws Exception {
// CREATE TABLE ss.mytable (
// field0 VARCHAR PRIMARY KEY
// field1 DOUBLE,
// field2 BINARY,
// field3 DATE,
// field4 SMALLINT
// )
String schemaName = "ss";
String query
= "UPDATE "+schemaName+".mytable"
+ " set field3=?," // DATE
+ " field4=?," // SMALLINT
+ " field1=?," // DOUBLE
+ " field2=?" // BINARY
+ " where field0 = ?";
SchemaPlus subSchema = buidlSchema(schemaName);
FrameworkConfig config = Frameworks.newConfigBuilder()
.parserConfig(SQL_PARSER_CONFIG)
.defaultSchema(subSchema)
.traitDefs(TRAITS)
// define the rules you want to apply
.programs(Programs.ofRules(Programs.RULE_SET))
.build();
Planner planner = Frameworks.getPlanner(config);
System.out.println("query:"+query);
SqlNode n = planner.parse(query);
n = planner.validate(n);
RelNode logicalPlan = planner.rel(n).project();
String dumpPlan = RelOptUtil.dumpPlan("-- Best Plan", logicalPlan,
SqlExplainFormat.TEXT,
SqlExplainLevel.ALL_ATTRIBUTES);
System.out.println(dumpPlan);
LogicalTableModify main = (LogicalTableModify) logicalPlan;
assertEquals(Arrays.asList("field3","field4","field1","field2"),
main.getUpdateColumnList());
List sourceExpressionList = main.getSourceExpressionList();
// failed: expected: but was:
RexDynamicParam field3value = (RexDynamicParam)
sourceExpressionList.get(0);
assertEquals("DATE", field3value.getType().getSqlTypeName());
RexDynamicParam field4value = (RexDynamicParam)
sourceExpressionList.get(1);
assertEquals("SMALLINT", field4value.getType().getSqlTypeName());
[jira] [Comment Edited] (CALCITE-3826) UPDATE assigns wrong type to bind variables
[
https://issues.apache.org/jira/browse/CALCITE-3826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17046603#comment-17046603
]
Enrico Olivelli edited comment on CALCITE-3826 at 2/27/20 1:10 PM:
---
[~zabetak] [~danny0405]
the problem is in the conversion to RelNode, it is not a planner problem.
I am trying to create a reproducer, outside Calcite project, you will be able
to convert to a Calcite test easily
{code}
SqlNode n = planner.parse(query);
n = planner.validate(n);
RelNode logicalPlan = planner.rel(n).project();}
{code}
here "logicalPlan" is already wrong
was (Author: eolivelli):
[~zabetak] [~danny0405]
the problem is in the conversion to RelNode, it is not a planner problem.
I am trying to create a reproducer, outside Calcite project, you will be able
to convert to a Calcite test easily
> UPDATE assigns wrong type to bind variables
> ---
>
> Key: CALCITE-3826
> URL: https://issues.apache.org/jira/browse/CALCITE-3826
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.22.0
>Reporter: Enrico Olivelli
>Priority: Blocker
>
> In 1.22.0rc1 I have found a problem about
> EnumerableTableModify#getSourceExpressionList
> It looks like it is not mapping correctly the expected datatypes of
> bind variables in queries like UPDATE table set a=?,b=? where pk=?.
> You can see the full SQL here in this commit in my test branch here
> https://github.com/diennea/herddb/pull/563/commits/157f927c9efe85cf7cac1370e1637b1c7ec46dff#diff-5d7594bc81ae0c92bbd33dee6c0d189aR2301
> My case is the following:
> Create a table:
> CREATE TABLE t1 (
> field0 int PRIMARY KEY,
> field1 VARCHAR(10),
> field2 VARCHAR(10),
> field3 INT,
> field4 INT,
> field5 VARCHAR(10)
> )
> UPDATE t1 SET field3 =?, field2=?, field4=?, field5=? where field0=?
> The Update maps to this Calcite plan:
> EnumerableTableModify(table=[[tblspace1, ip]], operation=[UPDATE],
> updateColumnList=[[field3, field2, field4, field5]],
> sourceExpressionList=[[?0, ?1, ?2, ?3]], flattened=[true]): rowcount =
> 1.0, cumulative cost = {2.5 rows, 10.5 cpu, 0.0 io}, id = 62
> EnumerableProject(field0=[$0], field1=[$1], field2=[$2],
> field3=[$3], field4=[$4], field5=[$5], EXPR$0=[?0], EXPR$1=[?1],
> EXPR$2=[?2], EXPR$3=[?3]): rowcount = 1.0, cumulative cost = {1.5
> rows, 10.5 cpu, 0.0 io}, id = 61
> EnumerableInterpreter: rowcount = 1.0, cumulative cost = {0.5
> rows, 0.5 cpu, 0.0 io}, id = 60
> BindableTableScan(table=[[tblspace1, ip]], filters=[[=($0,
> ?4)]]): rowcount = 1.0, cumulative cost = {0.005 rows, 0.01 cpu, 0.0
> io}, id = 45
> In particular the obeserved problem is:
> - the updateColumnList field is: field3, field2, field4, field5
> - but the bind variables have wrong type: VARCHAR, VARCHAR, INT, INT,
> expecting INT VARCHAR, INT VARCHAR
> even by changing the UPDATE command the types of bind variables stays the
> same,
> and they are the in the same order as in the CREATE TABLE STATEMENT,
> skipping the PK.
> It may be a regression of CALCITE-3672
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3826) UPDATE assigns wrong type to bind variables
[
https://issues.apache.org/jira/browse/CALCITE-3826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17046603#comment-17046603
]
Enrico Olivelli commented on CALCITE-3826:
--
[~zabetak] [~danny0405]
the problem is in the conversion to RelNode, it is not a planner problem.
I am trying to create a reproducer, outside Calcite project, you will be able
to convert to a Calcite test easily
> UPDATE assigns wrong type to bind variables
> ---
>
> Key: CALCITE-3826
> URL: https://issues.apache.org/jira/browse/CALCITE-3826
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.22.0
>Reporter: Enrico Olivelli
>Priority: Blocker
>
> In 1.22.0rc1 I have found a problem about
> EnumerableTableModify#getSourceExpressionList
> It looks like it is not mapping correctly the expected datatypes of
> bind variables in queries like UPDATE table set a=?,b=? where pk=?.
> You can see the full SQL here in this commit in my test branch here
> https://github.com/diennea/herddb/pull/563/commits/157f927c9efe85cf7cac1370e1637b1c7ec46dff#diff-5d7594bc81ae0c92bbd33dee6c0d189aR2301
> My case is the following:
> Create a table:
> CREATE TABLE t1 (
> field0 int PRIMARY KEY,
> field1 VARCHAR(10),
> field2 VARCHAR(10),
> field3 INT,
> field4 INT,
> field5 VARCHAR(10)
> )
> UPDATE t1 SET field3 =?, field2=?, field4=?, field5=? where field0=?
> The Update maps to this Calcite plan:
> EnumerableTableModify(table=[[tblspace1, ip]], operation=[UPDATE],
> updateColumnList=[[field3, field2, field4, field5]],
> sourceExpressionList=[[?0, ?1, ?2, ?3]], flattened=[true]): rowcount =
> 1.0, cumulative cost = {2.5 rows, 10.5 cpu, 0.0 io}, id = 62
> EnumerableProject(field0=[$0], field1=[$1], field2=[$2],
> field3=[$3], field4=[$4], field5=[$5], EXPR$0=[?0], EXPR$1=[?1],
> EXPR$2=[?2], EXPR$3=[?3]): rowcount = 1.0, cumulative cost = {1.5
> rows, 10.5 cpu, 0.0 io}, id = 61
> EnumerableInterpreter: rowcount = 1.0, cumulative cost = {0.5
> rows, 0.5 cpu, 0.0 io}, id = 60
> BindableTableScan(table=[[tblspace1, ip]], filters=[[=($0,
> ?4)]]): rowcount = 1.0, cumulative cost = {0.005 rows, 0.01 cpu, 0.0
> io}, id = 45
> In particular the obeserved problem is:
> - the updateColumnList field is: field3, field2, field4, field5
> - but the bind variables have wrong type: VARCHAR, VARCHAR, INT, INT,
> expecting INT VARCHAR, INT VARCHAR
> even by changing the UPDATE command the types of bind variables stays the
> same,
> and they are the in the same order as in the CREATE TABLE STATEMENT,
> skipping the PK.
> It may be a regression of CALCITE-3672
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3826) UPDATE assigns wrong type to bind variables
[
https://issues.apache.org/jira/browse/CALCITE-3826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17046566#comment-17046566
]
Enrico Olivelli commented on CALCITE-3826:
--
In HerdDB we tale the planetario computer with Enumerable convention and the we
build an execution layer, we are not using the built in Calcite executor
Thanks for taking a look.
I am not able to import Calcite in IntelliJ.
I am going to debug Calcite from inside HerdDB runtime, I hope to find the
point in which we assign the type for the bind variables.
It used to work in 1.19 I don't know for other Calcite releases.
This test about Updates was not present in the core HerdDB suite we found the
regression in a downstream application
> UPDATE assigns wrong type to bind variables
> ---
>
> Key: CALCITE-3826
> URL: https://issues.apache.org/jira/browse/CALCITE-3826
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.22.0
>Reporter: Enrico Olivelli
>Priority: Blocker
>
> In 1.22.0rc1 I have found a problem about
> EnumerableTableModify#getSourceExpressionList
> It looks like it is not mapping correctly the expected datatypes of
> bind variables in queries like UPDATE table set a=?,b=? where pk=?.
> You can see the full SQL here in this commit in my test branch here
> https://github.com/diennea/herddb/pull/563/commits/157f927c9efe85cf7cac1370e1637b1c7ec46dff#diff-5d7594bc81ae0c92bbd33dee6c0d189aR2301
> My case is the following:
> Create a table:
> CREATE TABLE t1 (
> field0 int PRIMARY KEY,
> field1 VARCHAR(10),
> field2 VARCHAR(10),
> field3 INT,
> field4 INT,
> field5 VARCHAR(10)
> )
> UPDATE t1 SET field3 =?, field2=?, field4=?, field5=? where field0=?
> The Update maps to this Calcite plan:
> EnumerableTableModify(table=[[tblspace1, ip]], operation=[UPDATE],
> updateColumnList=[[field3, field2, field4, field5]],
> sourceExpressionList=[[?0, ?1, ?2, ?3]], flattened=[true]): rowcount =
> 1.0, cumulative cost = {2.5 rows, 10.5 cpu, 0.0 io}, id = 62
> EnumerableProject(field0=[$0], field1=[$1], field2=[$2],
> field3=[$3], field4=[$4], field5=[$5], EXPR$0=[?0], EXPR$1=[?1],
> EXPR$2=[?2], EXPR$3=[?3]): rowcount = 1.0, cumulative cost = {1.5
> rows, 10.5 cpu, 0.0 io}, id = 61
> EnumerableInterpreter: rowcount = 1.0, cumulative cost = {0.5
> rows, 0.5 cpu, 0.0 io}, id = 60
> BindableTableScan(table=[[tblspace1, ip]], filters=[[=($0,
> ?4)]]): rowcount = 1.0, cumulative cost = {0.005 rows, 0.01 cpu, 0.0
> io}, id = 45
> In particular the obeserved problem is:
> - the updateColumnList field is: field3, field2, field4, field5
> - but the bind variables have wrong type: VARCHAR, VARCHAR, INT, INT,
> expecting INT VARCHAR, INT VARCHAR
> even by changing the UPDATE command the types of bind variables stays the
> same,
> and they are the in the same order as in the CREATE TABLE STATEMENT,
> skipping the PK.
> It may be a regression of CALCITE-3672
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3826) UPDATE assigns wrong type to bind variables
[
https://issues.apache.org/jira/browse/CALCITE-3826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17045396#comment-17045396
]
Enrico Olivelli commented on CALCITE-3826:
--
[~danny0405] Thanks for checking
is your test checking that at every bind variable the correct datatype is
assigned ?
I am not sure that checkPlanEquals tests for it
Can you also add some "WHERE "clause, in my example I have "WHERE
primarykeyfield=?" as well
Maybe the problem is not caused by your fix about "implicit type coercions"
I have already fallen into that lines of that commit
But the issue is real.
I am trying to get to it at speed, but these daysI have other priorities at
work so I have to work on it in my spare time
> UPDATE assigns wrong type to bind variables
> ---
>
> Key: CALCITE-3826
> URL: https://issues.apache.org/jira/browse/CALCITE-3826
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.22.0
>Reporter: Enrico Olivelli
>Priority: Blocker
>
> In 1.22.0rc1 I have found a problem about
> EnumerableTableModify#getSourceExpressionList
> It looks like it is not mapping correctly the expected datatypes of
> bind variables in queries like UPDATE table set a=?,b=? where pk=?.
> You can see the full SQL here in this commit in my test branch here
> https://github.com/diennea/herddb/pull/563/commits/157f927c9efe85cf7cac1370e1637b1c7ec46dff#diff-5d7594bc81ae0c92bbd33dee6c0d189aR2301
> My case is the following:
> Create a table:
> CREATE TABLE t1 (
> field0 int PRIMARY KEY,
> field1 VARCHAR(10),
> field2 VARCHAR(10),
> field3 INT,
> field4 INT,
> field5 VARCHAR(10)
> )
> UPDATE t1 SET field3 =?, field2=?, field4=?, field5=? where field0=?
> The Update maps to this Calcite plan:
> EnumerableTableModify(table=[[tblspace1, ip]], operation=[UPDATE],
> updateColumnList=[[field3, field2, field4, field5]],
> sourceExpressionList=[[?0, ?1, ?2, ?3]], flattened=[true]): rowcount =
> 1.0, cumulative cost = {2.5 rows, 10.5 cpu, 0.0 io}, id = 62
> EnumerableProject(field0=[$0], field1=[$1], field2=[$2],
> field3=[$3], field4=[$4], field5=[$5], EXPR$0=[?0], EXPR$1=[?1],
> EXPR$2=[?2], EXPR$3=[?3]): rowcount = 1.0, cumulative cost = {1.5
> rows, 10.5 cpu, 0.0 io}, id = 61
> EnumerableInterpreter: rowcount = 1.0, cumulative cost = {0.5
> rows, 0.5 cpu, 0.0 io}, id = 60
> BindableTableScan(table=[[tblspace1, ip]], filters=[[=($0,
> ?4)]]): rowcount = 1.0, cumulative cost = {0.005 rows, 0.01 cpu, 0.0
> io}, id = 45
> In particular the obeserved problem is:
> - the updateColumnList field is: field3, field2, field4, field5
> - but the bind variables have wrong type: VARCHAR, VARCHAR, INT, INT,
> expecting INT VARCHAR, INT VARCHAR
> even by changing the UPDATE command the types of bind variables stays the
> same,
> and they are the in the same order as in the CREATE TABLE STATEMENT,
> skipping the PK.
> It may be a regression of CALCITE-3672
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3769) Deprecate TableScanRule
[ https://issues.apache.org/jira/browse/CALCITE-3769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17045294#comment-17045294 ] Enrico Olivelli commented on CALCITE-3769: -- In my case the fix was easy, just to return "null" instead of throwing "not implemented". In HerdDB we are using Calcite internal APIS so it is not a big deal, we expect to need to be constantly following Calcite refactors. If Calcite with this change is able to create more clever plans in HerdDB we are very happy to see this kind of changes > Deprecate TableScanRule > --- > > Key: CALCITE-3769 > URL: https://issues.apache.org/jira/browse/CALCITE-3769 > Project: Calcite > Issue Type: Wish > Components: core >Affects Versions: 1.21.0 >Reporter: Danny Chen >Assignee: Danny Chen >Priority: Major > Labels: pull-request-available > Fix For: 1.22.0 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > The TableScanRule is the only planner rule that for a logical node(e.g. the > table scan), its function is to pass along the cluster object and invoke the > RelOptTable#toRel which is very trivial because it supplies only a simple > ToRelContext that does not support expanding view/passing table hints. > For rels that come from the sql-to-rel conversion, there is already a table > conversion logic[1]. This code gives a more powerful ToRelContext that has > the complete functionality. > The only reason that I saw the meaning of existing TableScanRule is for the > TableScan that comes from the RelBuilder#scan. > So I would suggest to deprecate the TableScanRule, instead, we support > translating the table directly in RelBuilder#scan, > -We also add a new interface RelBuilder#scan(Iterable tableNames, > ToRelContext context), so that user can pass in a more powerful ToRelContext > explicitly.- User can customize a TableScanFactory in the RelBuilder to do > this. > [1] > https://github.com/apache/calcite/blob/d6fa25cd11625ad7b4b74dafbd0211c701b38d49/core/src/main/java/org/apache/calcite/sql2rel/SqlToRelConverter.java#L3498 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-3826) UPDATE assigns wrong type to bind variables
Enrico Olivelli created CALCITE-3826:
Summary: UPDATE assigns wrong type to bind variables
Key: CALCITE-3826
URL: https://issues.apache.org/jira/browse/CALCITE-3826
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.22.0
Reporter: Enrico Olivelli
In 1.22.0rc1 I have found a problem about
EnumerableTableModify#getSourceExpressionList
It looks like it is not mapping correctly the expected datatypes of
bind variables in queries like UPDATE table set a=?,b=? where pk=?.
You can see the full SQL here in this commit in my test branch here
https://github.com/diennea/herddb/pull/563/commits/157f927c9efe85cf7cac1370e1637b1c7ec46dff#diff-5d7594bc81ae0c92bbd33dee6c0d189aR2301
My case is the following:
Create a table:
CREATE TABLE t1 (
field0 int PRIMARY KEY,
field1 VARCHAR(10),
field2 VARCHAR(10),
field3 INT,
field4 INT,
field5 VARCHAR(10)
)
UPDATE t1 SET field3 =?, field2=?, field4=?, field5=? where field0=?
The Update maps to this Calcite plan:
EnumerableTableModify(table=[[tblspace1, ip]], operation=[UPDATE],
updateColumnList=[[field3, field2, field4, field5]],
sourceExpressionList=[[?0, ?1, ?2, ?3]], flattened=[true]): rowcount =
1.0, cumulative cost = {2.5 rows, 10.5 cpu, 0.0 io}, id = 62
EnumerableProject(field0=[$0], field1=[$1], field2=[$2],
field3=[$3], field4=[$4], field5=[$5], EXPR$0=[?0], EXPR$1=[?1],
EXPR$2=[?2], EXPR$3=[?3]): rowcount = 1.0, cumulative cost = {1.5
rows, 10.5 cpu, 0.0 io}, id = 61
EnumerableInterpreter: rowcount = 1.0, cumulative cost = {0.5
rows, 0.5 cpu, 0.0 io}, id = 60
BindableTableScan(table=[[tblspace1, ip]], filters=[[=($0,
?4)]]): rowcount = 1.0, cumulative cost = {0.005 rows, 0.01 cpu, 0.0
io}, id = 45
In particular the obeserved problem is:
- the updateColumnList field is: field3, field2, field4, field5
- but the bind variables have wrong type: VARCHAR, VARCHAR, INT, INT,
expecting INT VARCHAR, INT VARCHAR
even by changing the UPDATE command the types of bind variables stays the same,
and they are the in the same order as in the CREATE TABLE STATEMENT,
skipping the PK.
It may be a regression of CALCITE-3672
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-2405) In Babel parser: allow to use some reserved keyword as identifier
[ https://issues.apache.org/jira/browse/CALCITE-2405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16932171#comment-16932171 ] Enrico Olivelli commented on CALCITE-2405: -- [~julianhyde] do you think it is feasible to add 'timestamp' ? is there any extension point to allow that keyword as nonReservedKeyword only in my project ? > In Babel parser: allow to use some reserved keyword as identifier > - > > Key: CALCITE-2405 > URL: https://issues.apache.org/jira/browse/CALCITE-2405 > Project: Calcite > Issue Type: New Feature > Components: babel >Affects Versions: 1.17.0 >Reporter: Enrico Olivelli >Assignee: Julian Hyde >Priority: Major > Fix For: 1.18.0 > > > I have some case of incompatibility between MySQL (actually on HerdDB which > is a replacement for MySQL) and Calcite around reserved identifiers. > * Allow a schema with name 'default' > * Allow a column name with name 'value' > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3347) IndexOutOfBoundsException in FixNullabilityShuttle when using FilterIntoJoinRule
[ https://issues.apache.org/jira/browse/CALCITE-3347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16929995#comment-16929995 ] Enrico Olivelli commented on CALCITE-3347: -- [~julianhyde] In fact the original test case is about using Bind Variables in sub queries :-) The query itself it not very useful but in the original test case we are testing bind variables in subqueries. > IndexOutOfBoundsException in FixNullabilityShuttle when using > FilterIntoJoinRule > > > Key: CALCITE-3347 > URL: https://issues.apache.org/jira/browse/CALCITE-3347 > Project: Calcite > Issue Type: Bug >Affects Versions: 1.21.0 >Reporter: Amit Chavan >Priority: Major > Attachments: TestCalcite.java > > > I am reporting a bug that happens in calcite 1.21 release. I have a query as > below > String query = "SELECT * FROM tblspace1.tsql where n1=? and k1 in (SELECT k1 > FROM tblspace1.tsql where n1=?)"; > > I am also attaching the unit test to reproduce this issue. > > The filterJoinRule throws an exception – > java.lang.RuntimeException: Error while applying rule > FilterJoinRule:FilterJoinRule:filter, args > [rel#39:EnumerableFilter.ENUMERABLE.[](input=RelSubset#38,condition==($1, > ?0)), > rel#176:EnumerableHashJoin.ENUMERABLE.[](left=RelSubset#17,right=RelSubset#73,condition==($0, > $3),joinType=semi)] > at > org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:235) > at > org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:631) > at org.apache.calcite.TestCalcite.testQuery(TestCalcite.java:199) > at org.apache.calcite.TestCalcite.problem_with_1_21(TestCalcite.java:256) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.junit.runner.JUnitCore.run(JUnitCore.java:137) > at > com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68) > at > com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47) > at > com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242) > at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70) > Caused by: java.lang.IndexOutOfBoundsException: index (3) must be less than > size (3) > at > com.google.common.base.Preconditions.checkElementIndex(Preconditions.java:310) > at > com.google.common.base.Preconditions.checkElementIndex(Preconditions.java:293) > at > com.google.common.collect.RegularImmutableList.get(RegularImmutableList.java:67) > at > com.google.common.collect.Lists$TransformingRandomAccessList.get(Lists.java:627) > at > org.apache.calcite.rex.RexUtil$FixNullabilityShuttle.visitInputRef(RexUtil.java:2529) > at > org.apache.calcite.rex.RexUtil$FixNullabilityShuttle.visitInputRef(RexUtil.java:2518) > at org.apache.calcite.rex.RexInputRef.accept(RexInputRef.java:112) > at org.apache.calcite.rex.RexShuttle.visitList(RexShuttle.java:149) > at org.apache.calcite.rex.RexShuttle.visitCall(RexShuttle.java:101) > at org.apache.calcite.rex.RexShuttle.visitCall(RexShuttle.java:34) > at org.apache.calcite.rex.RexCall.accept(RexCall.java:191) > at org.apache.calcite.rex.RexShuttle.apply(RexShuttle.java:277) > at org.apache.calcite.rex.RexShuttle.mutate(RexShuttle.java:239) > at org.apache.calcite.rex.RexShuttle.apply(RexShuttle.java:257) > at org.apache.calcite.rex.RexUtil.fixUp(RexUtil.java:1635) > at >
[jira] [Commented] (CALCITE-3347) FilterJoinRule throws exception in calcite 1.21. More details in description
[ https://issues.apache.org/jira/browse/CALCITE-3347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16929901#comment-16929901 ] Enrico Olivelli commented on CALCITE-3347: -- The errors happens in the context of unit tests suite of HerdDB > FilterJoinRule throws exception in calcite 1.21. More details in description > > > Key: CALCITE-3347 > URL: https://issues.apache.org/jira/browse/CALCITE-3347 > Project: Calcite > Issue Type: Bug >Affects Versions: 1.21.0 >Reporter: Amit Chavan >Priority: Major > Attachments: TestCalcite.java > > > I am reporting a bug that happens in calcite 1.21 release. I have a query as > below > String query = "SELECT * FROM tblspace1.tsql where n1=? and k1 in (SELECT k1 > FROM tblspace1.tsql where n1=?)"; > > I am also attaching the unit test to reproduce this issue. > > The filterJoinRule throws an exception – > java.lang.RuntimeException: Error while applying rule > FilterJoinRule:FilterJoinRule:filter, args > [rel#39:EnumerableFilter.ENUMERABLE.[](input=RelSubset#38,condition==($1, > ?0)), > rel#176:EnumerableHashJoin.ENUMERABLE.[](left=RelSubset#17,right=RelSubset#73,condition==($0, > $3),joinType=semi)] > at > org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:235) > at > org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:631) > at org.apache.calcite.TestCalcite.testQuery(TestCalcite.java:199) > at org.apache.calcite.TestCalcite.problem_with_1_21(TestCalcite.java:256) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.junit.runner.JUnitCore.run(JUnitCore.java:137) > at > com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68) > at > com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47) > at > com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242) > at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70) > Caused by: java.lang.IndexOutOfBoundsException: index (3) must be less than > size (3) > at > com.google.common.base.Preconditions.checkElementIndex(Preconditions.java:310) > at > com.google.common.base.Preconditions.checkElementIndex(Preconditions.java:293) > at > com.google.common.collect.RegularImmutableList.get(RegularImmutableList.java:67) > at > com.google.common.collect.Lists$TransformingRandomAccessList.get(Lists.java:627) > at > org.apache.calcite.rex.RexUtil$FixNullabilityShuttle.visitInputRef(RexUtil.java:2529) > at > org.apache.calcite.rex.RexUtil$FixNullabilityShuttle.visitInputRef(RexUtil.java:2518) > at org.apache.calcite.rex.RexInputRef.accept(RexInputRef.java:112) > at org.apache.calcite.rex.RexShuttle.visitList(RexShuttle.java:149) > at org.apache.calcite.rex.RexShuttle.visitCall(RexShuttle.java:101) > at org.apache.calcite.rex.RexShuttle.visitCall(RexShuttle.java:34) > at org.apache.calcite.rex.RexCall.accept(RexCall.java:191) > at org.apache.calcite.rex.RexShuttle.apply(RexShuttle.java:277) > at org.apache.calcite.rex.RexShuttle.mutate(RexShuttle.java:239) > at org.apache.calcite.rex.RexShuttle.apply(RexShuttle.java:257) > at org.apache.calcite.rex.RexUtil.fixUp(RexUtil.java:1635) > at > org.apache.calcite.rel.rules.FilterJoinRule.perform(FilterJoinRule.java:284) > at > org.apache.calcite.rel.rules.FilterJoinRule$FilterIntoJoinRule.onMatch(FilterJoinRule.java:383) > at >
[jira] [Commented] (CALCITE-2662) Planner: allow parsing directly a stream instead of a java.lang.String
[ https://issues.apache.org/jira/browse/CALCITE-2662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16708236#comment-16708236 ] Enrico Olivelli commented on CALCITE-2662: -- Thank you Julian and Vladmin for review > Planner: allow parsing directly a stream instead of a java.lang.String > -- > > Key: CALCITE-2662 > URL: https://issues.apache.org/jira/browse/CALCITE-2662 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.17.0 >Reporter: Enrico Olivelli >Assignee: Julian Hyde >Priority: Major > Fix For: 1.18.0 > > > In 1.17.0 the org.apache.calcite.tools.Planner interface only accept a > java.lang.String as input. > In order to reduce memory allocations and copies it will be useful that the > planner could accept the query in a more 'raw' format. > Creating a java.lang.String is very expensive, and if your "query" is coming > from the network (think about a Netty Direct memory ByteBuf) you are forced > to create a copy of the text of the query. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2662) Planner: allow parsing directly a stream instead of a java.lang.String
[ https://issues.apache.org/jira/browse/CALCITE-2662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16705766#comment-16705766 ] Enrico Olivelli commented on CALCITE-2662: -- [~julianhyde] patch is ready from my side. (sorry for double posting, I don't want which is the best place to comment Jira vs github) > Planner: allow parsing directly a stream instead of a java.lang.String > -- > > Key: CALCITE-2662 > URL: https://issues.apache.org/jira/browse/CALCITE-2662 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.17.0 >Reporter: Enrico Olivelli >Assignee: Julian Hyde >Priority: Major > > In 1.17.0 the org.apache.calcite.tools.Planner interface only accept a > java.lang.String as input. > In order to reduce memory allocations and copies it will be useful that the > planner could accept the query in a more 'raw' format. > Creating a java.lang.String is very expensive, and if your "query" is coming > from the network (think about a Netty Direct memory ByteBuf) you are forced > to create a copy of the text of the query. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2662) Planner: allow parsing directly a stream instead of a java.lang.String
[ https://issues.apache.org/jira/browse/CALCITE-2662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16703710#comment-16703710 ] Enrico Olivelli commented on CALCITE-2662: -- Just because I did not see any test case about the presence of such information. (No test fails setting a fixed null on that variable), so I am thinking that Calcite is reconstructing the query from the AST. I will add test cases around that variable. If we want it in the Reader version I am thinking about adding a Supplier to provide optionally the steing in case of error. This way on the moat common hot path (no error) I won't need to create the string > Planner: allow parsing directly a stream instead of a java.lang.String > -- > > Key: CALCITE-2662 > URL: https://issues.apache.org/jira/browse/CALCITE-2662 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.17.0 >Reporter: Enrico Olivelli >Assignee: Julian Hyde >Priority: Major > > In 1.17.0 the org.apache.calcite.tools.Planner interface only accept a > java.lang.String as input. > In order to reduce memory allocations and copies it will be useful that the > planner could accept the query in a more 'raw' format. > Creating a java.lang.String is very expensive, and if your "query" is coming > from the network (think about a Netty Direct memory ByteBuf) you are forced > to create a copy of the text of the query. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2662) Planner: allow parsing directly a stream instead of a java.lang.String
[ https://issues.apache.org/jira/browse/CALCITE-2662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16703682#comment-16703682 ] Enrico Olivelli commented on CALCITE-2662: -- I will add tests. As 'originalinput' query seems useless, do you want me to drop it or to keep it? I will revert the comments as well > Planner: allow parsing directly a stream instead of a java.lang.String > -- > > Key: CALCITE-2662 > URL: https://issues.apache.org/jira/browse/CALCITE-2662 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.17.0 >Reporter: Enrico Olivelli >Assignee: Julian Hyde >Priority: Major > > In 1.17.0 the org.apache.calcite.tools.Planner interface only accept a > java.lang.String as input. > In order to reduce memory allocations and copies it will be useful that the > planner could accept the query in a more 'raw' format. > Creating a java.lang.String is very expensive, and if your "query" is coming > from the network (think about a Netty Direct memory ByteBuf) you are forced > to create a copy of the text of the query. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2662) Planner: allow parsing directly a stream instead of a java.lang.String
[ https://issues.apache.org/jira/browse/CALCITE-2662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16703362#comment-16703362 ] Enrico Olivelli commented on CALCITE-2662: -- [~julianhyde] I have added a Proof-of-concept commit on top of the PR in which I am skipping the "old" constructor of SQLParser and so I am not retaining any more a reference to the original query. All tests in Calcite are passing, this makes me think that that information is not useful How does it sounds to you ? see https://github.com/apache/calcite/pull/906/commits/a22cfb9cc13a3dc8f6de53880870337fb01e6cbe > Planner: allow parsing directly a stream instead of a java.lang.String > -- > > Key: CALCITE-2662 > URL: https://issues.apache.org/jira/browse/CALCITE-2662 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.17.0 >Reporter: Enrico Olivelli >Assignee: Julian Hyde >Priority: Major > > In 1.17.0 the org.apache.calcite.tools.Planner interface only accept a > java.lang.String as input. > In order to reduce memory allocations and copies it will be useful that the > planner could accept the query in a more 'raw' format. > Creating a java.lang.String is very expensive, and if your "query" is coming > from the network (think about a Netty Direct memory ByteBuf) you are forced > to create a copy of the text of the query. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2662) Planner: allow parsing directly a stream instead of a java.lang.String
[ https://issues.apache.org/jira/browse/CALCITE-2662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16699484#comment-16699484 ] Enrico Olivelli commented on CALCITE-2662: -- Great. I will add the test soon This is the PR https://github.com/apache/calcite/pull/906 > Planner: allow parsing directly a stream instead of a java.lang.String > -- > > Key: CALCITE-2662 > URL: https://issues.apache.org/jira/browse/CALCITE-2662 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.17.0 >Reporter: Enrico Olivelli >Assignee: Julian Hyde >Priority: Major > > In 1.17.0 the org.apache.calcite.tools.Planner interface only accept a > java.lang.String as input. > In order to reduce memory allocations and copies it will be useful that the > planner could accept the query in a more 'raw' format. > Creating a java.lang.String is very expensive, and if your "query" is coming > from the network (think about a Netty Direct memory ByteBuf) you are forced > to create a copy of the text of the query. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2662) Planner: allow parsing directly a stream instead of a java.lang.String
[ https://issues.apache.org/jira/browse/CALCITE-2662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16697810#comment-16697810 ] Enrico Olivelli commented on CALCITE-2662: -- Sorry for late reply. I have updated the patch with a miminal "positive" test and change InputStream+Charset to java.io.Reader. The ideas around this change are the following: * I have a Netty Direct ByteBuf which is holding the query (which is coming from the network) * I know that the parser will split the query and create the AST, I can't prevent it from during so, we should stop using java.lang.String at all, and I think this change won't be acceptable in the short/mid term * If I have to create a java.lang.String (like not with Calcite 1.17) by sure I will duplicate the memory used for the query one more time (the AST will create many copied of part of the original String, and using a StringReader, which is also bad), and this will be on the heap. * Overall this change will save only an allocation of the byte[] in the heap (+ UTF8 encoder stuff), if you have "long" queries it will be a non-transcurable saving of resources. *I will keep on hold this change* until I finish the full story on my project and demonstrate that this change is usefull. I have also to create the test about error reporting, which in my case is not so important, but I understand that we have to be clear to what an user will gain and what it will lose. > Planner: allow parsing directly a stream instead of a java.lang.String > -- > > Key: CALCITE-2662 > URL: https://issues.apache.org/jira/browse/CALCITE-2662 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.17.0 >Reporter: Enrico Olivelli >Assignee: Julian Hyde >Priority: Major > > In 1.17.0 the org.apache.calcite.tools.Planner interface only accept a > java.lang.String as input. > In order to reduce memory allocations and copies it will be useful that the > planner could accept the query in a more 'raw' format. > Creating a java.lang.String is very expensive, and if your "query" is coming > from the network (think about a Netty Direct memory ByteBuf) you are forced > to create a copy of the text of the query. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-2662) Planner: allow parsing directly a stream instead of a java.lang.String
Enrico Olivelli created CALCITE-2662: Summary: Planner: allow parsing directly a stream instead of a java.lang.String Key: CALCITE-2662 URL: https://issues.apache.org/jira/browse/CALCITE-2662 Project: Calcite Issue Type: Improvement Components: core Affects Versions: 1.17.0 Reporter: Enrico Olivelli Assignee: Julian Hyde In 1.17.0 the org.apache.calcite.tools.Planner interface only accept a java.lang.String as input. In order to reduce memory allocations and copies it will be useful that the planner could accept the query in a more 'raw' format. Creating a java.lang.String is very expensive, and if your "query" is coming from the network (think about a Netty Direct memory ByteBuf) you are forced to create a copy of the text of the query. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2405) In Babel parser: allow to use some reserved keyword as identifier
[ https://issues.apache.org/jira/browse/CALCITE-2405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16672682#comment-16672682 ] Enrico Olivelli commented on CALCITE-2405: -- Great work. I took a look to the patch. I will test as soon as possible > In Babel parser: allow to use some reserved keyword as identifier > - > > Key: CALCITE-2405 > URL: https://issues.apache.org/jira/browse/CALCITE-2405 > Project: Calcite > Issue Type: New Feature > Components: babel >Affects Versions: 1.17.0 >Reporter: Enrico Olivelli >Assignee: Julian Hyde >Priority: Major > Fix For: 1.18.0 > > > I have some case of incompatibility between MySQL (actually on HerdDB which > is a replacement for MySQL) and Calcite around reserved identifiers. > * Allow a schema with name 'default' > * Allow a column name with name 'value' > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2406) SqlValidator: allow to use raw string literals for timestamps as in MySQL
[
https://issues.apache.org/jira/browse/CALCITE-2406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16672679#comment-16672679
]
Enrico Olivelli commented on CALCITE-2406:
--
[~julianhyde] I have updated the title and description, thanks.
When I will have cycles I can work on this
> SqlValidator: allow to use raw string literals for timestamps as in MySQL
> -
>
> Key: CALCITE-2406
> URL: https://issues.apache.org/jira/browse/CALCITE-2406
> Project: Calcite
> Issue Type: New Feature
> Components: babel
>Affects Versions: 1.17.0
>Reporter: Enrico Olivelli
>Assignee: Julian Hyde
>Priority: Major
>
> I have some case of incompatibility between MySQL (actually on HerdDB which
> is a replacement for MySQL) and Calcite around timestamp syntax.
> In MySQL it is legal to write timestamp literals in this form:
> INSERT INTO table(tscolum) values('2018-12-22 22:33:00.333')
> This is currently not possible for standard Calcite SQL Parser/Validator.
>
> It is not a requirement that the Validator converts the literal directly, a
> string will be fine, so that downstream the string will be parsed according
> to the Database/User/Session settings
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2406) SqlValidator: allow to use raw string literals for timestamps as in MySQL
[
https://issues.apache.org/jira/browse/CALCITE-2406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Enrico Olivelli updated CALCITE-2406:
-
Description:
I have some case of incompatibility between MySQL (actually on HerdDB which is
a replacement for MySQL) and Calcite around timestamp syntax.
In MySQL it is legal to write timestamp literals in this form:
INSERT INTO table(tscolum) values('2018-12-22 22:33:00.333')
This is currently not possible for standard Calcite SQL Parser/Validator.
It is not a requirement that the Validator converts the literal directly, a
string will be fine, so that downstream the string will be parsed according to
the Database/User/Session settings
was:
I have some case of incompatibility between MySQL (actually on HerdDB which is
a replacement for MySQL) and Calcite around timestamp syntax.
In MySQL it is legal to write timestamp literals in this form:
INSERT INTO table(tscolum) values('2018-12-22 22:33:00.333')
This is currently not possible for standard Calcite SQL Parser
> SqlValidator: allow to use raw string literals for timestamps as in MySQL
> -
>
> Key: CALCITE-2406
> URL: https://issues.apache.org/jira/browse/CALCITE-2406
> Project: Calcite
> Issue Type: New Feature
> Components: babel
>Affects Versions: 1.17.0
>Reporter: Enrico Olivelli
>Assignee: Julian Hyde
>Priority: Major
>
> I have some case of incompatibility between MySQL (actually on HerdDB which
> is a replacement for MySQL) and Calcite around timestamp syntax.
> In MySQL it is legal to write timestamp literals in this form:
> INSERT INTO table(tscolum) values('2018-12-22 22:33:00.333')
> This is currently not possible for standard Calcite SQL Parser/Validator.
>
> It is not a requirement that the Validator converts the literal directly, a
> string will be fine, so that downstream the string will be parsed according
> to the Database/User/Session settings
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2406) SqlValidator: allow to use raw string literals for timestamps as in MySQL
[
https://issues.apache.org/jira/browse/CALCITE-2406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Enrico Olivelli updated CALCITE-2406:
-
Summary: SqlValidator: allow to use raw string literals for timestamps as
in MySQL (was: In Babel parser: allow to use raw string literals for
timestamps as in MySQL)
> SqlValidator: allow to use raw string literals for timestamps as in MySQL
> -
>
> Key: CALCITE-2406
> URL: https://issues.apache.org/jira/browse/CALCITE-2406
> Project: Calcite
> Issue Type: New Feature
> Components: babel
>Affects Versions: 1.17.0
>Reporter: Enrico Olivelli
>Assignee: Julian Hyde
>Priority: Major
>
> I have some case of incompatibility between MySQL (actually on HerdDB which
> is a replacement for MySQL) and Calcite around timestamp syntax.
> In MySQL it is legal to write timestamp literals in this form:
> INSERT INTO table(tscolum) values('2018-12-22 22:33:00.333')
> This is currently not possible for standard Calcite SQL Parser
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2591) EnumerableDefaults#mergeJoin should throw error and not return incorrect results when inputs are not ordered
[
https://issues.apache.org/jira/browse/CALCITE-2591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16625105#comment-16625105
]
Enrico Olivelli commented on CALCITE-2591:
--
this is the patch
https://github.com/apache/calcite/pull/859
> EnumerableDefaults#mergeJoin should throw error and not return incorrect
> results when inputs are not ordered
>
>
> Key: CALCITE-2591
> URL: https://issues.apache.org/jira/browse/CALCITE-2591
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: Enrico Olivelli
>Assignee: Julian Hyde
>Priority: Critical
> Fix For: 1.18.0
>
>
> The merge join implementation should throw a runtime error in case of
> unsorted inputs.
>
> The assertion is already present but it is done with Java 'assert' keywork,
> this makes the assertion not to be evaluated in production.
> It happened in production that due to a bug (out of the scope of this issue)
> a merge join was fed by an input which was not sorted according to the merge
> sort keys
> This is current code in 1.17
> {code:java}
> int c = leftKey.compareTo(leftKey2);
> if (c != 0) {
> assert c < 0 : "not sorted";
> break;
> }{code}
>
> This change will enable that assertion even when Java assertions are not
> enabled.
> The impact is not very significant (a few CPU cycles) but prevents invalid
> results to be returned by the query.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CALCITE-2591) EnumerableDefaults#mergeJoin should throw error and not return incorrect results when inputs are not ordered
Enrico Olivelli created CALCITE-2591:
Summary: EnumerableDefaults#mergeJoin should throw error and not
return incorrect results when inputs are not ordered
Key: CALCITE-2591
URL: https://issues.apache.org/jira/browse/CALCITE-2591
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.17.0
Reporter: Enrico Olivelli
Assignee: Julian Hyde
Fix For: 1.18.0
The merge join implementation should throw a runtime error in case of unsorted
inputs.
The assertion is already present but it is done with Java 'assert' keywork,
this makes the assertion not to be evaluated in production.
It happened in production that due to a bug (out of the scope of this issue) a
merge join was fed by an input which was not sorted according to the merge sort
keys
This is current code in 1.17
{code:java}
int c = leftKey.compareTo(leftKey2);
if (c != 0) {
assert c < 0 : "not sorted";
break;
}{code}
This change will enable that assertion even when Java assertions are not
enabled.
The impact is not very significant (a few CPU cycles) but prevents invalid
results to be returned by the query.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2405) In Babel parser: allow to use some reserved keyword as identifier
[ https://issues.apache.org/jira/browse/CALCITE-2405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16599605#comment-16599605 ] Enrico Olivelli commented on CALCITE-2405: -- One of my customers reported also the will to create a table with name 'user' > In Babel parser: allow to use some reserved keyword as identifier > - > > Key: CALCITE-2405 > URL: https://issues.apache.org/jira/browse/CALCITE-2405 > Project: Calcite > Issue Type: New Feature > Components: babel >Affects Versions: 1.17.0 >Reporter: Enrico Olivelli >Assignee: Julian Hyde >Priority: Major > > I have some case of incompatibility between MySQL (actually on HerdDB which > is a replacement for MySQL) and Calcite around reserved identifiers. > * Allow a schema with name 'default' > * Allow a column name with name 'value' > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2489) Order of fields in JavaTypeFactoryImpl#createStructType is unstable
[
https://issues.apache.org/jira/browse/CALCITE-2489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16594109#comment-16594109
]
Enrico Olivelli commented on CALCITE-2489:
--
Totally agree with Julian
> Order of fields in JavaTypeFactoryImpl#createStructType is unstable
> ---
>
> Key: CALCITE-2489
> URL: https://issues.apache.org/jira/browse/CALCITE-2489
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: Vladimir Sitnikov
>Assignee: Julian Hyde
>Priority: Major
>
> {{JavaTypeFactoryImpl#createStructType}} relies on
> {{java.lang.Class#getFields}} to get public fields, however it does not sort
> elements.
> That might produce confusing results since Calcite relies on field order.
> That might result in flaky tests as well (as execution plans rely on field
> order).
> There are other {{#getFields}} usages.
> For instance:
> {{org.apache.calcite.rel.type.RelDataTypeFactoryImpl#fieldsOf}},
> {{org.apache.calcite.interpreter.TableScanNode#createQueryable}}, etc.
> It looks like we should implement Calcite-specific sort of the fields, and
> avoid adding new usages {{getFields}} to Calcite code.
> For instance:
> a) We might want to sort the fields from the super class to derived class.
> That is derived fields should come after the fields of a base class.
> b) When annotation is missing, we might want to sort fields on field
> names/field types (so the order is consistent)
> c) Add field-level annotation {{@CalciteField(int order)}}
> d) We might want to exclude certain fields by flagging with annotation as
> well (e.g. {{@CalciteField(exclude=true)}}
> Note: {{a}} and {{b}} are enough to get consistent field order.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2470) RelBuilder.project should combine expressions if underlying node is a Project
[
https://issues.apache.org/jira/browse/CALCITE-2470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16593411#comment-16593411
]
Enrico Olivelli commented on CALCITE-2470:
--
The order of the result of java.lang.Class#getFields is not deterministic
> RelBuilder.project should combine expressions if underlying node is a Project
> -
>
> Key: CALCITE-2470
> URL: https://issues.apache.org/jira/browse/CALCITE-2470
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.18.0
>
>
> The {{RelBuilder.project}} method should combine expressions if underlying
> node is a {{Project}}.
> For example, if {{r}} is a {{RelBuilder}} and its stack initially contains
> {code:java}
> Project(Scan(T), a, b, a + b as c){code}
> and we call (in pseudo-code)
> {code:java}
> r.project(a + c as d){code}
> then the result should be
> {code:java}
> Project(Scan(T), a + (a + b) as d){code}
> Today the result is
> {code:java}
> Project(Project(Scan(T), a, a + b as c), a + c as d){code}
> In some circumstances the result will be larger (i.e. contain more
> {{RexNode}} instances) but much more frequently the result will be smaller
> and simpler.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2457) Upgrade to JUnit 5
[ https://issues.apache.org/jira/browse/CALCITE-2457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16573016#comment-16573016 ] Enrico Olivelli edited comment on CALCITE-2457 at 8/8/18 10:56 AM: --- You will have to upgrade to latest maven surefire version, which has built-in and official in support for JUnit5 was (Author: eolivelli): You will have to upgrade to latest maven surefire version, which has built and official in support for JUnit5 > Upgrade to JUnit 5 > -- > > Key: CALCITE-2457 > URL: https://issues.apache.org/jira/browse/CALCITE-2457 > Project: Calcite > Issue Type: Improvement >Reporter: Vladimir Sitnikov >Assignee: Julian Hyde >Priority: Major > > JUnit 5 brings multiple useful features so tests are easier to read and write. > Is there something that blocks upgrading to JUnit 5? > By upgrade I mean bumping up the dependency version and creating new tests > with JUnit 5 features. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2457) Upgrade to JUnit 5
[ https://issues.apache.org/jira/browse/CALCITE-2457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16573016#comment-16573016 ] Enrico Olivelli commented on CALCITE-2457: -- You will have to upgrade to latest maven surefire version, which has built and official in support for JUnit5 > Upgrade to JUnit 5 > -- > > Key: CALCITE-2457 > URL: https://issues.apache.org/jira/browse/CALCITE-2457 > Project: Calcite > Issue Type: Improvement >Reporter: Vladimir Sitnikov >Assignee: Julian Hyde >Priority: Major > > JUnit 5 brings multiple useful features so tests are easier to read and write. > Is there something that blocks upgrading to JUnit 5? > By upgrade I mean bumping up the dependency version and creating new tests > with JUnit 5 features. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2395) Support SELECT xxx FROM TABLE FOR UPDATE syntax
[ https://issues.apache.org/jira/browse/CALCITE-2395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16549816#comment-16549816 ] Enrico Olivelli commented on CALCITE-2395: -- I am worrying about the validator: how can I validate the list of identifiers? About the rel2sql and planner: how can I bind each identifier with a table? I will have to generate a TableModify for each identifier and in case of empty list I will have to create one TableModify for each table referred by the query. Thank you for your help, I am still new to Calcite codebase > Support SELECT xxx FROM TABLE FOR UPDATE syntax > --- > > Key: CALCITE-2395 > URL: https://issues.apache.org/jira/browse/CALCITE-2395 > Project: Calcite > Issue Type: New Feature > Components: core >Affects Versions: 1.16.0 >Reporter: Enrico Olivelli >Assignee: Julian Hyde >Priority: Major > > I am using Calcite SQL Parser and Volcano Planner. > I need to support SQL syntax > SELECT ... FROM table FOR UPDATE > > see for instance PostGre docs > [https://www.postgresql.org/docs/9.5/static/sql-select.html.] > > I would like at least to support this syntax at SQL Parser level, the 'for > update' spec should be reported by the RelNode so that the system can take it > into account and perform explicit locking. > > Linked downstream project issue: > https://github.com/diennea/herddb/issues/228 > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2395) Support SELECT xxx FROM TABLE FOR UPDATE syntax
[ https://issues.apache.org/jira/browse/CALCITE-2395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16549688#comment-16549688 ] Enrico Olivelli commented on CALCITE-2395: -- Should be consider that the list of identifiers is a list of columns or a list of tables? It seems to be a list of tables in postgres and a list of cols in oracle/ibm > Support SELECT xxx FROM TABLE FOR UPDATE syntax > --- > > Key: CALCITE-2395 > URL: https://issues.apache.org/jira/browse/CALCITE-2395 > Project: Calcite > Issue Type: New Feature > Components: core >Affects Versions: 1.16.0 >Reporter: Enrico Olivelli >Assignee: Julian Hyde >Priority: Major > > I am using Calcite SQL Parser and Volcano Planner. > I need to support SQL syntax > SELECT ... FROM table FOR UPDATE > > see for instance PostGre docs > [https://www.postgresql.org/docs/9.5/static/sql-select.html.] > > I would like at least to support this syntax at SQL Parser level, the 'for > update' spec should be reported by the RelNode so that the system can take it > into account and perform explicit locking. > > Linked downstream project issue: > https://github.com/diennea/herddb/issues/228 > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2395) Support SELECT xxx FROM TABLE FOR UPDATE syntax
[
https://issues.apache.org/jira/browse/CALCITE-2395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16549397#comment-16549397
]
Enrico Olivelli commented on CALCITE-2395:
--
Except from SQL92 standard I cannot find any different cases of SELECT xxx FOR
UPDATE OF id,id,id
in PostGre seems that they support 'FOR UPDATE' with 'OF' and docs tell about
'*tables*'
see:
https://www.postgresql.org/docs/9.5/static/sql-select.html
In Oracle I am finding only examples like this
[https://www.techonthenet.com/oracle/cursors/for_update.php]
that is
{code:java}
CURSOR xxx IS
SELECT xxx
FROM ...
FOR UPDATE OF table.colum, table.column2
{code}
So it is only with 'CURSOR' and with a list of *columns* (not tables)
Therefore I can't find any support for "CURSOR IS" in Calcite.
I wonder if and how we can support "FOR UPDATE OF" in a consistent way with DMBS
Maybe I am missing one piece of the story, I am not an Oracle expert.
I am continuing the implementation following [~julianhyde] 's suggestions, but
I would like to have a 'real world' counterpart of what I an doing.
Any help/guidance is really appreciated
> Support SELECT xxx FROM TABLE FOR UPDATE syntax
> ---
>
> Key: CALCITE-2395
> URL: https://issues.apache.org/jira/browse/CALCITE-2395
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Affects Versions: 1.16.0
>Reporter: Enrico Olivelli
>Assignee: Julian Hyde
>Priority: Major
>
> I am using Calcite SQL Parser and Volcano Planner.
> I need to support SQL syntax
> SELECT ... FROM table FOR UPDATE
>
> see for instance PostGre docs
> [https://www.postgresql.org/docs/9.5/static/sql-select.html.]
>
> I would like at least to support this syntax at SQL Parser level, the 'for
> update' spec should be reported by the RelNode so that the system can take it
> into account and perform explicit locking.
>
> Linked downstream project issue:
> https://github.com/diennea/herddb/issues/228
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2395) Support SELECT xxx FROM TABLE FOR UPDATE syntax
[
https://issues.apache.org/jira/browse/CALCITE-2395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16547665#comment-16547665
]
Enrico Olivelli commented on CALCITE-2395:
--
[~julianhyde] regarding SqlUpdatabilityClause classI have created such
class because the standard talks about this syntax
{code:java}
SELECT FOR READ_ONLY{code}
so I image in the future we will have some "kind" of SqlUpdatabilityClause,
like FOR_UPDATE and FOR_READ_ONLY
I can add support for "READ_ONLY" in this work, although it is not strictly
needed and I don't think it is really useful.
So I can use a simple SqlNodeList, with these conventions:
* null -> no clause at all
* empty -> select .. for update (without table list)
* non empty -> select ... for update of table,table,table
I have used "updatability clause" term because SQL uses that name, but if we
don't want to include "FOR READ_ONLY" it makes sense to call this "lock clause"
Okay for the other comments.
I will move forward, please give me another "ACK" and I will drop
SqlUpdatabilityClause, just to confirm that we are not interested in "FOR
READ_ONLY"
Cheers
> Support SELECT xxx FROM TABLE FOR UPDATE syntax
> ---
>
> Key: CALCITE-2395
> URL: https://issues.apache.org/jira/browse/CALCITE-2395
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Affects Versions: 1.16.0
>Reporter: Enrico Olivelli
>Assignee: Julian Hyde
>Priority: Major
>
> I am using Calcite SQL Parser and Volcano Planner.
> I need to support SQL syntax
> SELECT ... FROM table FOR UPDATE
>
> see for instance PostGre docs
> [https://www.postgresql.org/docs/9.5/static/sql-select.html.]
>
> I would like at least to support this syntax at SQL Parser level, the 'for
> update' spec should be reported by the RelNode so that the system can take it
> into account and perform explicit locking.
>
> Linked downstream project issue:
> https://github.com/diennea/herddb/issues/228
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2395) Support SELECT xxx FROM TABLE FOR UPDATE syntax
[ https://issues.apache.org/jira/browse/CALCITE-2395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16547144#comment-16547144 ] Enrico Olivelli commented on CALCITE-2395: -- [~julianhyde] [~michaelmior] I have pushed the first commit of my work for early review if you have cycles. [https://github.com/apache/calcite/pull/763] Just to see if I have taken the good way, or if the approach is not appropriate. This commit introduces the UpdatabilityClause at SQL Parser Level, nothing more. I imagine the next step is to run thru the Validator and then thru SqlToRelConverter, is it true ? Third stepPlanner rules Fourth step...SQLImplementor Am I missing something ? Thanks > Support SELECT xxx FROM TABLE FOR UPDATE syntax > --- > > Key: CALCITE-2395 > URL: https://issues.apache.org/jira/browse/CALCITE-2395 > Project: Calcite > Issue Type: New Feature > Components: core >Affects Versions: 1.16.0 >Reporter: Enrico Olivelli >Assignee: Julian Hyde >Priority: Major > > I am using Calcite SQL Parser and Volcano Planner. > I need to support SQL syntax > SELECT ... FROM table FOR UPDATE > > see for instance PostGre docs > [https://www.postgresql.org/docs/9.5/static/sql-select.html.] > > I would like at least to support this syntax at SQL Parser level, the 'for > update' spec should be reported by the RelNode so that the system can take it > into account and perform explicit locking. > > Linked downstream project issue: > https://github.com/diennea/herddb/issues/228 > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2406) In Babel parser: allow to use raw string literals for timestamps as in MySQL
[
https://issues.apache.org/jira/browse/CALCITE-2406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Enrico Olivelli updated CALCITE-2406:
-
Description:
I have some case of incompatibility between MySQL (actually on HerdDB which is
a replacement for MySQL) and Calcite around timestamp syntax.
In MySQL it is legal to write timestamp literals in this form:
INSERT INTO table(tscolum) values('2018-12-22 22:33:00.333')
This is currently not possible for standard Calcite SQL Parser
was:
I have some case of incompatibility between MySQL (actually on HerdDB which is
a replacement for MySQL) and Calcite around reserved identifiers.
* Allow a schema with name 'default'
* Allow a column name with name 'value'
> In Babel parser: allow to use raw string literals for timestamps as in MySQL
>
>
> Key: CALCITE-2406
> URL: https://issues.apache.org/jira/browse/CALCITE-2406
> Project: Calcite
> Issue Type: New Feature
> Components: babel
>Affects Versions: 1.17.0
>Reporter: Enrico Olivelli
>Assignee: Julian Hyde
>Priority: Major
>
> I have some case of incompatibility between MySQL (actually on HerdDB which
> is a replacement for MySQL) and Calcite around timestamp syntax.
> In MySQL it is legal to write timestamp literals in this form:
> INSERT INTO table(tscolum) values('2018-12-22 22:33:00.333')
> This is currently not possible for standard Calcite SQL Parser
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CALCITE-2406) In Babel parser: allow to use raw string literals for timestamps as in MySQL
Enrico Olivelli created CALCITE-2406: Summary: In Babel parser: allow to use raw string literals for timestamps as in MySQL Key: CALCITE-2406 URL: https://issues.apache.org/jira/browse/CALCITE-2406 Project: Calcite Issue Type: New Feature Components: babel Affects Versions: 1.17.0 Reporter: Enrico Olivelli Assignee: Julian Hyde I have some case of incompatibility between MySQL (actually on HerdDB which is a replacement for MySQL) and Calcite around reserved identifiers. * Allow a schema with name 'default' * Allow a column name with name 'value' -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-2405) In Babel parser: allow to use some reserved keyword as identifier
Enrico Olivelli created CALCITE-2405: Summary: In Babel parser: allow to use some reserved keyword as identifier Key: CALCITE-2405 URL: https://issues.apache.org/jira/browse/CALCITE-2405 Project: Calcite Issue Type: New Feature Components: babel Affects Versions: 1.17.0 Reporter: Enrico Olivelli Assignee: Julian Hyde I have some case of incompatibility between MySQL (actually on HerdDB which is a replacement for MySQL) and Calcite around reserved identifiers. * Allow a schema with name 'default' * Allow a column name with name 'value' -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2304) In Babel parser, allow Hive-style syntax "LEFT SEMI JOIN"
[ https://issues.apache.org/jira/browse/CALCITE-2304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16536708#comment-16536708 ] Enrico Olivelli commented on CALCITE-2304: -- [~julianhyde] I have tested this change immediately on a downstream project and it is working very well (at least tests are not failing just by switching SQL parser factory and conformance to Babel). I will create a couple of issues, hopefully I will be able to send some patch these days > In Babel parser, allow Hive-style syntax "LEFT SEMI JOIN" > - > > Key: CALCITE-2304 > URL: https://issues.apache.org/jira/browse/CALCITE-2304 > Project: Calcite > Issue Type: Bug > Components: babel >Reporter: Julian Hyde >Assignee: Julian Hyde >Priority: Major > Fix For: 1.17.0 > > > In Babel parser, allow Hive-style syntax "LEFT SEMI JOIN". > This case is a fairly modest extension to syntax, and can be used as a > template for other changes to the Babel parser. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2395) Support SELECT xxx FROM TABLE FOR UPDATE syntax
[ https://issues.apache.org/jira/browse/CALCITE-2395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16532993#comment-16532993 ] Enrico Olivelli commented on CALCITE-2395: -- Got it, thanks Julian > Support SELECT xxx FROM TABLE FOR UPDATE syntax > --- > > Key: CALCITE-2395 > URL: https://issues.apache.org/jira/browse/CALCITE-2395 > Project: Calcite > Issue Type: New Feature > Components: core >Affects Versions: 1.16.0 >Reporter: Enrico Olivelli >Assignee: Julian Hyde >Priority: Major > > I am using Calcite SQL Parser and Volcano Planner. > I need to support SQL syntax > SELECT ... FROM table FOR UPDATE > > see for instance PostGre docs > [https://www.postgresql.org/docs/9.5/static/sql-select.html.] > > I would like at least to support this syntax at SQL Parser level, the 'for > update' spec should be reported by the RelNode so that the system can take it > into account and perform explicit locking. > > Linked downstream project issue: > https://github.com/diennea/herddb/issues/228 > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2395) Support SELECT xxx FROM TABLE FOR UPDATE syntax
[ https://issues.apache.org/jira/browse/CALCITE-2395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16532444#comment-16532444 ] Enrico Olivelli commented on CALCITE-2395: -- [~julianhyde] [~michaelmior] I am trying to find the best reference for SQL, honestly I never read that suite of standard documents. I have found these documents, if you usually use some better reference will tel me, I will be happy to 'study' [https://ronsavage.github.io/SQL/sql-92.bnf.html#xref-updatability%20clause] [https://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt] [~julianhyde] It seems to me that 'FOR UPDATE OF" is about 'column names' and not "table names", I never used that syntax so I will have to study. Given that I am able to represent such 'updatability clause' in Calcite SQL Parser..how do you expect it to be represented in RelNode AST model ? I expect it to be preserved somehow during Planner work. I expect it to be preserved while reconstructing SQL for standard DBMS (for this part I am not an user of Calcite, I don't know this part at all) I will start working on this an submit a patch, in order to start the discussion on some real example > Support SELECT xxx FROM TABLE FOR UPDATE syntax > --- > > Key: CALCITE-2395 > URL: https://issues.apache.org/jira/browse/CALCITE-2395 > Project: Calcite > Issue Type: New Feature > Components: core >Affects Versions: 1.16.0 >Reporter: Enrico Olivelli >Assignee: Julian Hyde >Priority: Major > > I am using Calcite SQL Parser and Volcano Planner. > I need to support SQL syntax > SELECT ... FROM table FOR UPDATE > > see for instance PostGre docs > [https://www.postgresql.org/docs/9.5/static/sql-select.html.] > > I would like at least to support this syntax at SQL Parser level, the 'for > update' spec should be reported by the RelNode so that the system can take it > into account and perform explicit locking. > > Linked downstream project issue: > https://github.com/diennea/herddb/issues/228 > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-2395) Support SELECT xxx FROM TABLE FOR UPDATE syntax
Enrico Olivelli created CALCITE-2395: Summary: Support SELECT xxx FROM TABLE FOR UPDATE syntax Key: CALCITE-2395 URL: https://issues.apache.org/jira/browse/CALCITE-2395 Project: Calcite Issue Type: New Feature Components: core Affects Versions: 1.16.0 Reporter: Enrico Olivelli Assignee: Julian Hyde I am using Calcite SQL Parser and Volcano Planner. I need to support SQL syntax SELECT ... FROM table FOR UPDATE see for instance PostGre docs [https://www.postgresql.org/docs/9.5/static/sql-select.html.] I would like at least to support this syntax at SQL Parser level, the 'for update' spec should be reported by the RelNode so that the system can take it into account and perform explicit locking. Linked downstream project issue: https://github.com/diennea/herddb/issues/228 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2280) Liberal "babel" parser that accepts all SQL dialects
[ https://issues.apache.org/jira/browse/CALCITE-2280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16520767#comment-16520767 ] Enrico Olivelli commented on CALCITE-2280: -- I guess we should wait for Calcite 1.18 for this great feature. Not really a problem, we will have more time to give feedback once this patch is merged to master. Thank you again Julian > Liberal "babel" parser that accepts all SQL dialects > > > Key: CALCITE-2280 > URL: https://issues.apache.org/jira/browse/CALCITE-2280 > Project: Calcite > Issue Type: Bug > Components: babel >Reporter: Julian Hyde >Assignee: Julian Hyde >Priority: Major > Fix For: 1.17.0 > > > Create a parser that accepts all SQL dialects. > It would accept common dialects such as Oracle, MySQL, PostgreSQL, BigQuery. > If you have preferred dialects, please let us know in the comments section. > (If you're willing to work on a particular dialect, even better!) > We would do this in a new module, inheriting and extending the parser in the > same way that the DDL parser in the "server" module does. > This would be a messy and difficult project, because we would have to comply > with the rules of each parser (and its set of built-in functions) rather than > writing the rules as we would like them to be. That's why I would keep it out > of the core parser. But it would also have large benefits. > This would be new territory Calcite: as a tool for manipulating/understanding > SQL, not (necessarily) for relational algebra or execution. > Some possible uses: > * analyze query lineage (what tables and columns are used in a query); > * translate from one SQL dialect to another (using the JDBC adapter to > generate SQL in the target dialect); > * a "deep" compatibility mode (much more comprehensive than the current > compatibility mode) where Calcite could pretend to be, say, Oracle; > * SQL parser as a service: a REST call gives a SQL query, and returns a JSON > or XML document with the parse tree. > If you can think of interesting uses, please discuss in the comments. > There are similarities with Uber's > [QueryParser|https://eng.uber.com/queryparser/] tool. Maybe we can > collaborate, or make use of their test cases. > We will need a lot of sample queries. If you are able to contribute sample > queries for particular dialects, please discuss in the comments section. It > would be good if the sample queries are based on a familiar schema (e.g. > scott or foodmart) but we can be flexible about this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2280) Liberal "babel" parser that accepts all SQL dialects
[ https://issues.apache.org/jira/browse/CALCITE-2280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16461549#comment-16461549 ] Enrico Olivelli commented on CALCITE-2280: -- Great work! I have to face several problems due to some incompatibility with Mysql list of reserved words. Like 'timestamp', 'value' as column name and 'default' as schema name. I will be happy to contribute queries and eventually a more Mysql friendly parser > Liberal "babel" parser that accepts all SQL dialects > > > Key: CALCITE-2280 > URL: https://issues.apache.org/jira/browse/CALCITE-2280 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Julian Hyde >Priority: Major > > Create a parser that accepts all SQL dialects. > It would accept common dialects such as Oracle, MySQL, PostgreSQL, BigQuery. > If you have preferred dialects, please let us know in the comments section. > (If you're willing to work on a particular dialect, even better!) > We would do this in a new module, inheriting and extending the parser in the > same way that the DDL parser in the "server" module does. > This would be a messy and difficult project, because we would have to comply > with the rules of each parser (and its set of built-in functions) rather than > writing the rules as we would like them to be. That's why I would keep it out > of the core parser. But it would also have large benefits. > This would be new territory Calcite: as a tool for manipulating/understanding > SQL, not (necessarily) for relational algebra or execution. > Some possible uses: > * analyze query lineage (what tables and columns are used in a query); > * translate from one SQL dialect to another (using the JDBC adapter to > generate SQL in the target dialect); > * a "deep" compatibility mode (much more comprehensive than the current > compatibility mode) where Calcite could pretend to be, say, Oracle; > * SQL parser as a service: a REST call gives a SQL query, and returns a JSON > or XML document with the parse tree. > If you can think of interesting uses, please discuss in the comments. > There are similarities with Uber's > [QueryParser|https://eng.uber.com/queryparser/] tool. Maybe we can > collaborate, or make use of their test cases. > We will need a lot of sample queries. If you are able to contribute sample > queries for particular dialects, please discuss in the comments section. It > would be good if the sample queries are based on a familiar schema (e.g. > scott or foodmart) but we can be flexible about this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2261) Switch calcite-core to JDK8
[ https://issues.apache.org/jira/browse/CALCITE-2261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16443616#comment-16443616 ] Enrico Olivelli commented on CALCITE-2261: -- [~julianhyde] I have addressed your comments. I did not find a standard format for Bug.upgrade reports, I did my best Link to patch for reference: [https://github.com/apache/calcite/pull/667] > Switch calcite-core to JDK8 > --- > > Key: CALCITE-2261 > URL: https://issues.apache.org/jira/browse/CALCITE-2261 > Project: Calcite > Issue Type: Improvement > Components: build >Affects Versions: 1.16.0 >Reporter: Enrico Olivelli >Assignee: Julian Hyde >Priority: Major > Fix For: 1.17.0 > > > Currently (1.16) Calcilte core is compiled for JDK 1.7. > Just switching maven-compiler-plugin to 1.8 is not enough because of a bug of > Janino > [https://github.com/janino-compiler/janino/issues/47] > reported by Vova > > As a workaround to that bug we have to add a default method implementation > for SchemaPlus#getSubSchema > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2261) Switch calcite-core to JDK8
[ https://issues.apache.org/jira/browse/CALCITE-2261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enrico Olivelli updated CALCITE-2261: - Summary: Switch calcite-core to JDK8 (was: Switch calcilte-core to JDK8) > Switch calcite-core to JDK8 > --- > > Key: CALCITE-2261 > URL: https://issues.apache.org/jira/browse/CALCITE-2261 > Project: Calcite > Issue Type: Improvement > Components: build >Affects Versions: 1.16.0 >Reporter: Enrico Olivelli >Assignee: Julian Hyde >Priority: Major > Fix For: 1.17.0 > > > Currently (1.16) Calcilte core is compiled for JDK 1.7. > Just switching maven-compiler-plugin to 1.8 is not enough because of a bug of > Janino > [https://github.com/janino-compiler/janino/issues/47] > reported by Vova > > As a workaround to that bug we have to add a default method implementation > for SchemaPlus#getSubSchema > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-2261) Switch calcilte-core to JDK8
Enrico Olivelli created CALCITE-2261: Summary: Switch calcilte-core to JDK8 Key: CALCITE-2261 URL: https://issues.apache.org/jira/browse/CALCITE-2261 Project: Calcite Issue Type: Improvement Components: build Affects Versions: 1.16.0 Reporter: Enrico Olivelli Assignee: Julian Hyde Fix For: 1.17.0 Currently (1.16) Calcilte core is compiled for JDK 1.7. Just switching maven-compiler-plugin to 1.8 is not enough because of a bug of Janino [https://github.com/janino-compiler/janino/issues/47] reported by Vova As a workaround to that bug we have to add a default method implementation for SchemaPlus#getSubSchema -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2172) Document IDE setup for project contribution
[ https://issues.apache.org/jira/browse/CALCITE-2172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16356936#comment-16356936 ] Enrico Olivelli commented on CALCITE-2172: -- My two cents, I am a NetBeans user: 1) clone Calcite 2) Open Calcite directory with NetBeans > Document IDE setup for project contribution > --- > > Key: CALCITE-2172 > URL: https://issues.apache.org/jira/browse/CALCITE-2172 > Project: Calcite > Issue Type: Improvement > Components: site >Reporter: Edmon Begoli >Assignee: Edmon Begoli >Priority: Trivial > Labels: documentation > Original Estimate: 48h > Remaining Estimate: 48h > > Document the IDE setup for Calcite development. > Start with IDEA, document Eclipse, NetBeans, and maybe VIM and Emacs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2118) Field names are not preserved by RelToSqlConverter
[ https://issues.apache.org/jira/browse/CALCITE-2118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16311803#comment-16311803 ] Enrico Olivelli commented on CALCITE-2118: -- What is your usecase? Hiw do you get to that plan? For instance inside the planner the information about the original query is lost, but there are ways to get it having the original nides which represent the query > Field names are not preserved by RelToSqlConverter > -- > > Key: CALCITE-2118 > URL: https://issues.apache.org/jira/browse/CALCITE-2118 > Project: Calcite > Issue Type: Bug >Affects Versions: 1.15.0 >Reporter: Austin Haas >Assignee: Julian Hyde >Priority: Minor > > This: > LogicalProject(x=[$0]) > LogicalTableScan(table=[[t]]) > is converted to: > "SELECT *\nFROM `t`" > when it should be: > "SELECT `a` AS `x`\nFROM `t`" > Thread: > http://mail-archives.apache.org/mod_mbox/calcite-dev/201801.mbox/%3C2F715F75-40CD-4053-9C83-7B4550848557%40HealthSparq.com%3E -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CALCITE-2100) Ability not to use DriverManager to run only the planner
Enrico Olivelli created CALCITE-2100:
Summary: Ability not to use DriverManager to run only the planner
Key: CALCITE-2100
URL: https://issues.apache.org/jira/browse/CALCITE-2100
Project: Calcite
Issue Type: Improvement
Components: core
Affects Versions: 1.15.0
Reporter: Enrico Olivelli
Assignee: Julian Hyde
At this point:
{code:java}
org.apache.calcite.tools.Frameworks.withPrepare(Frameworks.java:156)
at org.apache.calcite.tools.Frameworks.withPlanner(Frameworks.java:111)
at org.apache.calcite.prepare.PlannerImpl.ready(PlannerImpl.java:145)
at org.apache.calcite.prepare.PlannerImpl.parse(PlannerImpl.java:175)
{code}
we are going to use DriverManager to get a connection to "jdbc:calcite:", this
is not very efficient and in some cases it can lead to errors if the
o.a.c.jdbc.Driver has not been loaded.
It would be great to be able to skip this step and be able to use the Planner
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-2054) Error while validating UPDATE with dynamic parameter in SET clause
[
https://issues.apache.org/jira/browse/CALCITE-2054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16268176#comment-16268176
]
Enrico Olivelli commented on CALCITE-2054:
--
Thank you so much!
> Error while validating UPDATE with dynamic parameter in SET clause
> --
>
> Key: CALCITE-2054
> URL: https://issues.apache.org/jira/browse/CALCITE-2054
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.15.0
>Reporter: Enrico Olivelli
>Assignee: Julian Hyde
> Fix For: 1.15.0
>
>
> with a simple UPDATE like:
> UPDATE mytable set a=? where b=1
> I get the error below.
> The "Table" is a ModifiableTable + ScannableTable, with "a" of type INTEGER
> and "b" of type VARCHAR
> Any hint ?
> Thank you
> Enrico
> {code}
> org.apache.calcite.runtime.CalciteContextException: At line 1, column 30:
> Illegal use of dynamic parameter
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:463)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:803)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:788)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:4651)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.inferUnknownTypes(SqlValidatorImpl.java:1694)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.inferUnknownTypes(SqlValidatorImpl.java:1769)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.expandSelectItem(SqlValidatorImpl.java:457)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.expandStar(SqlValidatorImpl.java:347)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectList(SqlToRelConverter.java:3709)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:663)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:620)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertUpdate(SqlToRelConverter.java:3398)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3048)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:556)
> at org.apache.calcite.prepare.PlannerImpl.rel(PlannerImpl.java:240)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-2061) Support for dynamic parameters in offset/fetch (limit)
[ https://issues.apache.org/jira/browse/CALCITE-2061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16264315#comment-16264315 ] Enrico Olivelli commented on CALCITE-2061: -- Patch updated > Support for dynamic parameters in offset/fetch (limit) > -- > > Key: CALCITE-2061 > URL: https://issues.apache.org/jira/browse/CALCITE-2061 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.15.0 >Reporter: Enrico Olivelli >Assignee: Julian Hyde >Priority: Critical > > Fetch/Offset already support RexNode, it will be useful to support Dynamic > parameters as well. > This implementation is needed to be able to run Yahoo YCSB JDBC benchmarks > which does large use of this syntax > select LIMIT ? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-2061) Support for dynamic parameters in offset/fetch (limit)
[ https://issues.apache.org/jira/browse/CALCITE-2061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16264200#comment-16264200 ] Enrico Olivelli commented on CALCITE-2061: -- I think I have found the way. Will send updates soon > Support for dynamic parameters in offset/fetch (limit) > -- > > Key: CALCITE-2061 > URL: https://issues.apache.org/jira/browse/CALCITE-2061 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.15.0 >Reporter: Enrico Olivelli >Assignee: Julian Hyde >Priority: Critical > > Fetch/Offset already support RexNode, it will be useful to support Dynamic > parameters as well. > This implementation is needed to be able to run Yahoo YCSB JDBC benchmarks > which does large use of this syntax > select LIMIT ? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-2061) Support for dynamic parameters in offset/fetch (limit)
[ https://issues.apache.org/jira/browse/CALCITE-2061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16263920#comment-16263920 ] Enrico Olivelli commented on CALCITE-2061: -- I will fix checkstyle as last task > Support for dynamic parameters in offset/fetch (limit) > -- > > Key: CALCITE-2061 > URL: https://issues.apache.org/jira/browse/CALCITE-2061 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.15.0 >Reporter: Enrico Olivelli >Assignee: Julian Hyde >Priority: Critical > > Fetch/Offset already support RexNode, it will be useful to support Dynamic > parameters as well. > This implementation is needed to be able to run Yahoo YCSB JDBC benchmarks > which does large use of this syntax > select LIMIT ? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-2061) Support for dynamic parameters in offset/fetch (limit)
[ https://issues.apache.org/jira/browse/CALCITE-2061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16263919#comment-16263919 ] Enrico Olivelli commented on CALCITE-2061: -- Yep, the error is clear. But I can't find any way to create an accessor to dynamic parameters as Expression. It seems that Expressions.dynamic() is not implemented and there is not used full method in RexToLixTranslator to achieve the goal, I am tring to write is but there is a lot of stuff to learn. Do I have to implement such support ? I see in RexToLixTranslator that some support for dynamic parameters is already present. For the scope of my urgent needs the patch is working, because I only use the planner. If it is a big change as there is no such support dyn parameters in Expressions and you need to close 1.15 next week I propose to split this issue in two parts, merge this part in 1.15 and I volounteer to finish the work as soon as possible but it will go to 1.16. The support for dynamic limits in planner for me is really important as it is used in YCSB for benchmarks. I will continue my search for the best implementation, maybe the impl is trivial but I am a newbie to Calcite codebase > Support for dynamic parameters in offset/fetch (limit) > -- > > Key: CALCITE-2061 > URL: https://issues.apache.org/jira/browse/CALCITE-2061 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.15.0 >Reporter: Enrico Olivelli >Assignee: Julian Hyde >Priority: Critical > > Fetch/Offset already support RexNode, it will be useful to support Dynamic > parameters as well. > This implementation is needed to be able to run Yahoo YCSB JDBC benchmarks > which does large use of this syntax > select LIMIT ? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (CALCITE-2061) Support for dynamic parameters in offset/fetch (limit)
[
https://issues.apache.org/jira/browse/CALCITE-2061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16262796#comment-16262796
]
Enrico Olivelli edited comment on CALCITE-2061 at 11/22/17 3:31 PM:
I have integrated your changes [~julianhyde]
I can't find how to resolve the value for RexNode which is not a literal
this is an example of error
can you point me the correct way to do it ?
{code}
java.lang.AssertionError: not a literal: ?0
at org.apache.calcite.rex.RexLiteral.findValue(RexLiteral.java:960)
at org.apache.calcite.rex.RexLiteral.intValue(RexLiteral.java:935)
at
org.apache.calcite.adapter.enumerable.EnumerableLimit.implement(EnumerableLimit.java:120)
at
org.apache.calcite.adapter.enumerable.EnumerableRelImplementor.visitChild(EnumerableRelImplementor.java:103)
at
org.apache.calcite.adapter.enumerable.EnumerableCalc.implement(EnumerableCalc.java:124)
at
org.apache.calcite.adapter.enumerable.EnumerableRelImplementor.implementRoot(EnumerableRelImplementor.java:108)
at
org.apache.calcite.adapter.enumerable.EnumerableInterpretable.toBindable(EnumerableInterpretable.java:92)
at
org.apache.calcite.prepare.CalcitePrepareImpl$CalcitePreparingStmt.implement(CalcitePrepareImpl.java:1261)
at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:330)
at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:229)
{core}
was (Author: eolivelli):
I have integrated your changes [~julianhyde]
I can't find how to resolve the value for RexNode which is not a literal
this is an example of error
can you point me the correct way to do it ?
{code}
java.lang.AssertionError: not a literal: ?0
at org.apache.calcite.rex.RexLiteral.findValue(RexLiteral.java:960)
at org.apache.calcite.rex.RexLiteral.intValue(RexLiteral.java:935)
at
org.apache.calcite.adapter.enumerable.EnumerableLimit.implement(EnumerableLimit.java:120)
at
org.apache.calcite.adapter.enumerable.EnumerableRelImplementor.visitChild(EnumerableRelImplementor.java:103)
at
org.apache.calcite.adapter.enumerable.EnumerableCalc.implement(EnumerableCalc.java:124)
at
org.apache.calcite.adapter.enumerable.EnumerableRelImplementor.implementRoot(EnumerableRelImplementor.java:108)
at
org.apache.calcite.adapter.enumerable.EnumerableInterpretable.toBindable(EnumerableInterpretable.java:92)
at
org.apache.calcite.prepare.CalcitePrepareImpl$CalcitePreparingStmt.implement(CalcitePrepareImpl.java:1261)
at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:330)
at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:229)
{core}
> Support for dynamic parameters in offset/fetch (limit)
> --
>
> Key: CALCITE-2061
> URL: https://issues.apache.org/jira/browse/CALCITE-2061
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.15.0
>Reporter: Enrico Olivelli
>Assignee: Julian Hyde
>Priority: Critical
>
> Fetch/Offset already support RexNode, it will be useful to support Dynamic
> parameters as well.
> This implementation is needed to be able to run Yahoo YCSB JDBC benchmarks
> which does large use of this syntax
> select LIMIT ?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-2061) Support for dynamic parameters in offset/fetch (limit)
[
https://issues.apache.org/jira/browse/CALCITE-2061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16262796#comment-16262796
]
Enrico Olivelli commented on CALCITE-2061:
--
I have integrated your changes [~julianhyde]
I can't find how to resolve the value for RexNode which is not a literal
this is an example of error
can you point me the correct way to do it ?
{code}
java.lang.AssertionError: not a literal: ?0
at org.apache.calcite.rex.RexLiteral.findValue(RexLiteral.java:960)
at org.apache.calcite.rex.RexLiteral.intValue(RexLiteral.java:935)
at
org.apache.calcite.adapter.enumerable.EnumerableLimit.implement(EnumerableLimit.java:120)
at
org.apache.calcite.adapter.enumerable.EnumerableRelImplementor.visitChild(EnumerableRelImplementor.java:103)
at
org.apache.calcite.adapter.enumerable.EnumerableCalc.implement(EnumerableCalc.java:124)
at
org.apache.calcite.adapter.enumerable.EnumerableRelImplementor.implementRoot(EnumerableRelImplementor.java:108)
at
org.apache.calcite.adapter.enumerable.EnumerableInterpretable.toBindable(EnumerableInterpretable.java:92)
at
org.apache.calcite.prepare.CalcitePrepareImpl$CalcitePreparingStmt.implement(CalcitePrepareImpl.java:1261)
at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:330)
at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:229)
{core}
> Support for dynamic parameters in offset/fetch (limit)
> --
>
> Key: CALCITE-2061
> URL: https://issues.apache.org/jira/browse/CALCITE-2061
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.15.0
>Reporter: Enrico Olivelli
>Assignee: Julian Hyde
>Priority: Critical
>
> Fetch/Offset already support RexNode, it will be useful to support Dynamic
> parameters as well.
> This implementation is needed to be able to run Yahoo YCSB JDBC benchmarks
> which does large use of this syntax
> select LIMIT ?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-2054) Parser error on trivial UPDATE with dynamic parameters
[
https://issues.apache.org/jira/browse/CALCITE-2054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16262762#comment-16262762
]
Enrico Olivelli commented on CALCITE-2054:
--
[~julianhyde] I have added the test as requested.
> Parser error on trivial UPDATE with dynamic parameters
> --
>
> Key: CALCITE-2054
> URL: https://issues.apache.org/jira/browse/CALCITE-2054
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.15.0
>Reporter: Enrico Olivelli
>Assignee: Julian Hyde
>
> with a simple UPDATE like:
> UPDATE mytable set a=? where b=1
> I get the error below.
> The "Table" is a ModifiableTable + ScannableTable, with "a" of type INTEGER
> and "b" of type VARCHAR
> Any hint ?
> Thank you
> Enrico
> {code}
> org.apache.calcite.runtime.CalciteContextException: At line 1, column 30:
> Illegal use of dynamic parameter
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:463)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:803)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:788)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:4651)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.inferUnknownTypes(SqlValidatorImpl.java:1694)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.inferUnknownTypes(SqlValidatorImpl.java:1769)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.expandSelectItem(SqlValidatorImpl.java:457)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.expandStar(SqlValidatorImpl.java:347)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectList(SqlToRelConverter.java:3709)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:663)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:620)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertUpdate(SqlToRelConverter.java:3398)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3048)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:556)
> at org.apache.calcite.prepare.PlannerImpl.rel(PlannerImpl.java:240)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-2054) Parser error on trivial UPDATE with dynamic parameters
[
https://issues.apache.org/jira/browse/CALCITE-2054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16260745#comment-16260745
]
Enrico Olivelli commented on CALCITE-2054:
--
[~julianhyde] I think I have finally found the right fix for this.
The problem is that expandStar loses information about pre-validated node types.
I have updated the patch
https://github.com/apache/calcite/pull/568/files
thanks
> Parser error on trivial UPDATE with dynamic parameters
> --
>
> Key: CALCITE-2054
> URL: https://issues.apache.org/jira/browse/CALCITE-2054
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.15.0
>Reporter: Enrico Olivelli
>Assignee: Julian Hyde
>
> with a simple UPDATE like:
> UPDATE mytable set a=? where b=1
> I get the error below.
> The "Table" is a ModifiableTable + ScannableTable, with "a" of type INTEGER
> and "b" of type VARCHAR
> Any hint ?
> Thank you
> Enrico
> {code}
> org.apache.calcite.runtime.CalciteContextException: At line 1, column 30:
> Illegal use of dynamic parameter
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:463)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:803)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:788)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:4651)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.inferUnknownTypes(SqlValidatorImpl.java:1694)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.inferUnknownTypes(SqlValidatorImpl.java:1769)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.expandSelectItem(SqlValidatorImpl.java:457)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.expandStar(SqlValidatorImpl.java:347)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectList(SqlToRelConverter.java:3709)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:663)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:620)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertUpdate(SqlToRelConverter.java:3398)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3048)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:556)
> at org.apache.calcite.prepare.PlannerImpl.rel(PlannerImpl.java:240)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-2061) Support for dynamic parameters in offset/fetch (limit)
[ https://issues.apache.org/jira/browse/CALCITE-2061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16260401#comment-16260401 ] Enrico Olivelli commented on CALCITE-2061: -- this is the patch https://github.com/apache/calcite/pull/569/files > Support for dynamic parameters in offset/fetch (limit) > -- > > Key: CALCITE-2061 > URL: https://issues.apache.org/jira/browse/CALCITE-2061 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.15.0 >Reporter: Enrico Olivelli >Assignee: Julian Hyde >Priority: Critical > > Fetch/Offset already support RexNode, it will be useful to support Dynamic > parameters as well. > This implementation is needed to be able to run Yahoo YCSB JDBC benchmarks > which does large use of this syntax > select LIMIT ? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-2054) Parser error on trivial UPDATE with dynamic parameters
[
https://issues.apache.org/jira/browse/CALCITE-2054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16259783#comment-16259783
]
Enrico Olivelli commented on CALCITE-2054:
--
The more I am working on Calcite the more I am getting a general view at least
for the converter/valudator/planner part. While working on the patch for
dynamic parameters for fetch/offset I think I have understood what you are
suggesting.
I will update this patch and send the other one.
> Parser error on trivial UPDATE with dynamic parameters
> --
>
> Key: CALCITE-2054
> URL: https://issues.apache.org/jira/browse/CALCITE-2054
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.15.0
>Reporter: Enrico Olivelli
>Assignee: Julian Hyde
>
> with a simple UPDATE like:
> UPDATE mytable set a=? where b=1
> I get the error below.
> The "Table" is a ModifiableTable + ScannableTable, with "a" of type INTEGER
> and "b" of type VARCHAR
> Any hint ?
> Thank you
> Enrico
> {code}
> org.apache.calcite.runtime.CalciteContextException: At line 1, column 30:
> Illegal use of dynamic parameter
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:463)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:803)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:788)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:4651)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.inferUnknownTypes(SqlValidatorImpl.java:1694)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.inferUnknownTypes(SqlValidatorImpl.java:1769)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.expandSelectItem(SqlValidatorImpl.java:457)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.expandStar(SqlValidatorImpl.java:347)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectList(SqlToRelConverter.java:3709)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:663)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:620)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertUpdate(SqlToRelConverter.java:3398)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3048)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:556)
> at org.apache.calcite.prepare.PlannerImpl.rel(PlannerImpl.java:240)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-2061) Support for dynamic parameters in offset/fetch (limit)
[ https://issues.apache.org/jira/browse/CALCITE-2061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16258421#comment-16258421 ] Enrico Olivelli commented on CALCITE-2061: -- [~michaelmior] [~julianhyde] I would like to pick this up. I am starting an implementation, for me is blocker > Support for dynamic parameters in offset/fetch (limit) > -- > > Key: CALCITE-2061 > URL: https://issues.apache.org/jira/browse/CALCITE-2061 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.15.0 >Reporter: Enrico Olivelli >Assignee: Julian Hyde >Priority: Critical > > Fetch/Offset already support RexNode, it will be useful to support Dynamic > parameters as well. > This implementation is needed to be able to run Yahoo YCSB JDBC benchmarks > which does large use of this syntax > select LIMIT ? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CALCITE-2061) Support for dynamic parameters in offset/fetch (limit)
Enrico Olivelli created CALCITE-2061: Summary: Support for dynamic parameters in offset/fetch (limit) Key: CALCITE-2061 URL: https://issues.apache.org/jira/browse/CALCITE-2061 Project: Calcite Issue Type: Improvement Components: core Affects Versions: 1.15.0 Reporter: Enrico Olivelli Assignee: Julian Hyde Priority: Critical Fetch/Offset already support RexNode, it will be useful to support Dynamic parameters as well. This implementation is needed to be able to run Yahoo YCSB JDBC benchmarks which does large use of this syntax select LIMIT ? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-2054) Parser error on trivial UPDATE with dynamic parameters
[
https://issues.apache.org/jira/browse/CALCITE-2054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16258410#comment-16258410
]
Enrico Olivelli commented on CALCITE-2054:
--
Maybe another alternative option would be to implement a flag to allow unknown
type for dynamic parameters, letting the implementation to deal with casts
this will allow queries like
select ? as 'foo', a,b from my table which are not possible at the moment
> Parser error on trivial UPDATE with dynamic parameters
> --
>
> Key: CALCITE-2054
> URL: https://issues.apache.org/jira/browse/CALCITE-2054
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.15.0
>Reporter: Enrico Olivelli
>Assignee: Julian Hyde
>
> with a simple UPDATE like:
> UPDATE mytable set a=? where b=1
> I get the error below.
> The "Table" is a ModifiableTable + ScannableTable, with "a" of type INTEGER
> and "b" of type VARCHAR
> Any hint ?
> Thank you
> Enrico
> {code}
> org.apache.calcite.runtime.CalciteContextException: At line 1, column 30:
> Illegal use of dynamic parameter
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:463)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:803)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:788)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:4651)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.inferUnknownTypes(SqlValidatorImpl.java:1694)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.inferUnknownTypes(SqlValidatorImpl.java:1769)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.expandSelectItem(SqlValidatorImpl.java:457)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.expandStar(SqlValidatorImpl.java:347)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectList(SqlToRelConverter.java:3709)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:663)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:620)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertUpdate(SqlToRelConverter.java:3398)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3048)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:556)
> at org.apache.calcite.prepare.PlannerImpl.rel(PlannerImpl.java:240)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (CALCITE-2054) Parser error on trivial UPDATE with dynamic parameters
[
https://issues.apache.org/jira/browse/CALCITE-2054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16257982#comment-16257982
]
Enrico Olivelli edited comment on CALCITE-2054 at 11/18/17 8:27 AM:
[~julianhyde] I found a simpler approach, that is to use setValidatedNodeType
in convertUpdate to instruct the validator about inferred type of additional
SqlNodes in the selectlist for the update.
This way the change is minimal: no changes to signatures of methods.
but I did not change the code according to your suggestion "You might need to
change the tree-walk so that inferUnknownTypes gets called everywhere"
https://github.com/apache/calcite/pull/568/files
I appreciate your help
was (Author: eolivelli):
[~julianhyde] I found simpler approach, that is to use setValidatedNodeType in
convertUpdate to instrct the validator of inferred type of additional SqlNodes
in the selectlist for the update.
This way the change is minimal: no changes to signatures of methods.
but I did not change the code according to your suggestion "You might need to
change the tree-walk so that inferUnknownTypes gets called everywhere"
https://github.com/apache/calcite/pull/568/files
I appreciate your help
> Parser error on trivial UPDATE with dynamic parameters
> --
>
> Key: CALCITE-2054
> URL: https://issues.apache.org/jira/browse/CALCITE-2054
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.15.0
>Reporter: Enrico Olivelli
>Assignee: Julian Hyde
>
> with a simple UPDATE like:
> UPDATE mytable set a=? where b=1
> I get the error below.
> The "Table" is a ModifiableTable + ScannableTable, with "a" of type INTEGER
> and "b" of type VARCHAR
> Any hint ?
> Thank you
> Enrico
> {code}
> org.apache.calcite.runtime.CalciteContextException: At line 1, column 30:
> Illegal use of dynamic parameter
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:463)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:803)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:788)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:4651)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.inferUnknownTypes(SqlValidatorImpl.java:1694)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.inferUnknownTypes(SqlValidatorImpl.java:1769)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.expandSelectItem(SqlValidatorImpl.java:457)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.expandStar(SqlValidatorImpl.java:347)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectList(SqlToRelConverter.java:3709)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:663)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:620)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertUpdate(SqlToRelConverter.java:3398)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3048)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:556)
> at org.apache.calcite.prepare.PlannerImpl.rel(PlannerImpl.java:240)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (CALCITE-2054) Parser error on trivial UPDATE with dynamic parameters
[
https://issues.apache.org/jira/browse/CALCITE-2054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16257982#comment-16257982
]
Enrico Olivelli edited comment on CALCITE-2054 at 11/18/17 8:26 AM:
[~julianhyde] I found simpler approach, that is to use setValidatedNodeType in
convertUpdate to instrct the validator of inferred type of additional SqlNodes
in the selectlist for the update.
This way the change is minimal: no changes to signatures of methods.
but I did not change the code according to your suggestion "You might need to
change the tree-walk so that inferUnknownTypes gets called everywhere"
https://github.com/apache/calcite/pull/568/files
I appreciate your help
was (Author: eolivelli):
[~julianhyde] I found simpler approach, that is to use setValidatedNodeType in
convertUpdate to instrct the validator of inferred type of additional SqlNodes
in the selectlist for the update.
This way the change is minimal: no changes to signatures of methods.
but I did not change the code according to your suggestion "You might need to
change the tree-walk so that inferUnknownTypes gets called everywhere"
https://github.com/apache/calcite/pull/568
I appreciate your help
> Parser error on trivial UPDATE with dynamic parameters
> --
>
> Key: CALCITE-2054
> URL: https://issues.apache.org/jira/browse/CALCITE-2054
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.15.0
>Reporter: Enrico Olivelli
>Assignee: Julian Hyde
>
> with a simple UPDATE like:
> UPDATE mytable set a=? where b=1
> I get the error below.
> The "Table" is a ModifiableTable + ScannableTable, with "a" of type INTEGER
> and "b" of type VARCHAR
> Any hint ?
> Thank you
> Enrico
> {code}
> org.apache.calcite.runtime.CalciteContextException: At line 1, column 30:
> Illegal use of dynamic parameter
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:463)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:803)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:788)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:4651)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.inferUnknownTypes(SqlValidatorImpl.java:1694)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.inferUnknownTypes(SqlValidatorImpl.java:1769)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.expandSelectItem(SqlValidatorImpl.java:457)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.expandStar(SqlValidatorImpl.java:347)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectList(SqlToRelConverter.java:3709)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:663)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:620)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertUpdate(SqlToRelConverter.java:3398)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3048)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:556)
> at org.apache.calcite.prepare.PlannerImpl.rel(PlannerImpl.java:240)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-2054) Parser error on trivial UPDATE with dynamic parameters
[
https://issues.apache.org/jira/browse/CALCITE-2054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16257982#comment-16257982
]
Enrico Olivelli commented on CALCITE-2054:
--
[~julianhyde] I found simpler approach, that is to use setValidatedNodeType in
convertUpdate to instrct the validator of inferred type of additional SqlNodes
in the selectlist for the update.
This way the change is minimal: no changes to signatures of methods.
but I did not change the code according to your suggestion "You might need to
change the tree-walk so that inferUnknownTypes gets called everywhere"
https://github.com/apache/calcite/pull/568
I appreciate your help
> Parser error on trivial UPDATE with dynamic parameters
> --
>
> Key: CALCITE-2054
> URL: https://issues.apache.org/jira/browse/CALCITE-2054
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.15.0
>Reporter: Enrico Olivelli
>Assignee: Julian Hyde
>
> with a simple UPDATE like:
> UPDATE mytable set a=? where b=1
> I get the error below.
> The "Table" is a ModifiableTable + ScannableTable, with "a" of type INTEGER
> and "b" of type VARCHAR
> Any hint ?
> Thank you
> Enrico
> {code}
> org.apache.calcite.runtime.CalciteContextException: At line 1, column 30:
> Illegal use of dynamic parameter
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:463)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:803)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:788)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:4651)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.inferUnknownTypes(SqlValidatorImpl.java:1694)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.inferUnknownTypes(SqlValidatorImpl.java:1769)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.expandSelectItem(SqlValidatorImpl.java:457)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.expandStar(SqlValidatorImpl.java:347)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectList(SqlToRelConverter.java:3709)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:663)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:620)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertUpdate(SqlToRelConverter.java:3398)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3048)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:556)
> at org.apache.calcite.prepare.PlannerImpl.rel(PlannerImpl.java:240)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-2054) Parser error on trivial UPDATE with dynamic parameters
[
https://issues.apache.org/jira/browse/CALCITE-2054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16257579#comment-16257579
]
Enrico Olivelli commented on CALCITE-2054:
--
Thanks
I will debug deeper SqlToRelConverter.
I am getting the same error for some other kind of INSERT I will add testcases
as well.
Will send a new patch as soon as I find the culprit
> Parser error on trivial UPDATE with dynamic parameters
> --
>
> Key: CALCITE-2054
> URL: https://issues.apache.org/jira/browse/CALCITE-2054
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.15.0
>Reporter: Enrico Olivelli
>Assignee: Julian Hyde
>
> with a simple UPDATE like:
> UPDATE mytable set a=? where b=1
> I get the error below.
> The "Table" is a ModifiableTable + ScannableTable, with "a" of type INTEGER
> and "b" of type VARCHAR
> Any hint ?
> Thank you
> Enrico
> {code}
> org.apache.calcite.runtime.CalciteContextException: At line 1, column 30:
> Illegal use of dynamic parameter
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:463)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:803)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:788)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:4651)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.inferUnknownTypes(SqlValidatorImpl.java:1694)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.inferUnknownTypes(SqlValidatorImpl.java:1769)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.expandSelectItem(SqlValidatorImpl.java:457)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.expandStar(SqlValidatorImpl.java:347)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectList(SqlToRelConverter.java:3709)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:663)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:620)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertUpdate(SqlToRelConverter.java:3398)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3048)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:556)
> at org.apache.calcite.prepare.PlannerImpl.rel(PlannerImpl.java:240)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-2054) Parser error on trivial UPDATE with dynamic parameters
[
https://issues.apache.org/jira/browse/CALCITE-2054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16256880#comment-16256880
]
Enrico Olivelli commented on CALCITE-2054:
--
I have tried to solve this problem, this is the patch
https://github.com/apache/calcite/pull/568
> Parser error on trivial UPDATE with dynamic parameters
> --
>
> Key: CALCITE-2054
> URL: https://issues.apache.org/jira/browse/CALCITE-2054
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.15.0
>Reporter: Enrico Olivelli
>Assignee: Julian Hyde
>
> with a simple UPDATE like:
> UPDATE mytable set a=? where b=1
> I get the error below.
> The "Table" is a ModifiableTable + ScannableTable, with "a" of type INTEGER
> and "b" of type VARCHAR
> Any hint ?
> Thank you
> Enrico
> {code}
> org.apache.calcite.runtime.CalciteContextException: At line 1, column 30:
> Illegal use of dynamic parameter
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:463)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:803)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:788)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:4651)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.inferUnknownTypes(SqlValidatorImpl.java:1694)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.inferUnknownTypes(SqlValidatorImpl.java:1769)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.expandSelectItem(SqlValidatorImpl.java:457)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.expandStar(SqlValidatorImpl.java:347)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectList(SqlToRelConverter.java:3709)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:663)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:620)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertUpdate(SqlToRelConverter.java:3398)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3048)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:556)
> at org.apache.calcite.prepare.PlannerImpl.rel(PlannerImpl.java:240)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (CALCITE-2054) Parser error on trivial UPDATE with dynamic parameters
[
https://issues.apache.org/jira/browse/CALCITE-2054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Enrico Olivelli updated CALCITE-2054:
-
Description:
with a simple UPDATE like:
UPDATE mytable set a=? where b=1
I get the error below.
The "Table" is a ModifiableTable + ScannableTable, with "a" of type INTEGER and
"b" of type VARCHAR
Any hint ?
Thank you
Enrico
{code}
org.apache.calcite.runtime.CalciteContextException: At line 1, column 30:
Illegal use of dynamic parameter
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at
org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:463)
at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:803)
at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:788)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:4651)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.inferUnknownTypes(SqlValidatorImpl.java:1694)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.inferUnknownTypes(SqlValidatorImpl.java:1769)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.expandSelectItem(SqlValidatorImpl.java:457)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.expandStar(SqlValidatorImpl.java:347)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectList(SqlToRelConverter.java:3709)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:663)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:620)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertUpdate(SqlToRelConverter.java:3398)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3048)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:556)
at org.apache.calcite.prepare.PlannerImpl.rel(PlannerImpl.java:240)
{code}
was:
with a simple UPDATE like:
UPDATE mytable set a=? where b=?
I get the error below.
The "Table" is a ModifiableTable + ScannableTable, with "a" of type INTEGER and
"b" of type VARCHAR
Any hint ?
Thank you
Enrico
{code}
org.apache.calcite.runtime.CalciteContextException: At line 1, column 30:
Illegal use of dynamic parameter
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at
org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:463)
at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:803)
at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:788)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:4651)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.inferUnknownTypes(SqlValidatorImpl.java:1694)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.inferUnknownTypes(SqlValidatorImpl.java:1769)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.expandSelectItem(SqlValidatorImpl.java:457)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.expandStar(SqlValidatorImpl.java:347)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectList(SqlToRelConverter.java:3709)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:663)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:620)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertUpdate(SqlToRelConverter.java:3398)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3048)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:556)
at org.apache.calcite.prepare.PlannerImpl.rel(PlannerImpl.java:240)
{code}
> Parser error on trivial UPDATE with dynamic parameters
> --
>
> Key: CALCITE-2054
> URL: https://issues.apache.org/jira/browse/CALCITE-2054
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.15.0
>Reporter: Enrico Olivelli
>Assignee: Julian Hyde
>
> with a simple UPDATE like:
> UPDATE mytable set a=? where b=1
> I get the error below.
> The "Table" is a ModifiableTable + ScannableTable, with "a"
[jira] [Commented] (CALCITE-2054) Parser error on trivial UPDATE with dynamic parameters
[
https://issues.apache.org/jira/browse/CALCITE-2054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16256604#comment-16256604
]
Enrico Olivelli commented on CALCITE-2054:
--
Can you give me some hint?
I will be happy to submit a patch.
I am still a newbie in Calcite.
How is it supposed to be bound the type for a dynamic parameter?
In this case I think we could derive the type from the column which is going to
be updated/filtered.
Another approach would be to drop the assertion in this special case. I don't
think it is bad to have a unknown type in this case, but maybe I am missing
something.
/cc [~michaelmior]
> Parser error on trivial UPDATE with dynamic parameters
> --
>
> Key: CALCITE-2054
> URL: https://issues.apache.org/jira/browse/CALCITE-2054
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.15.0
>Reporter: Enrico Olivelli
>Assignee: Julian Hyde
>
> with a simple UPDATE like:
> UPDATE mytable set a=? where b=?
> I get the error below.
> The "Table" is a ModifiableTable + ScannableTable, with "a" of type INTEGER
> and "b" of type VARCHAR
> Any hint ?
> Thank you
> Enrico
> {code}
> org.apache.calcite.runtime.CalciteContextException: At line 1, column 30:
> Illegal use of dynamic parameter
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:463)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:803)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:788)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:4651)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.inferUnknownTypes(SqlValidatorImpl.java:1694)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.inferUnknownTypes(SqlValidatorImpl.java:1769)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.expandSelectItem(SqlValidatorImpl.java:457)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.expandStar(SqlValidatorImpl.java:347)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectList(SqlToRelConverter.java:3709)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:663)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:620)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertUpdate(SqlToRelConverter.java:3398)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3048)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:556)
> at org.apache.calcite.prepare.PlannerImpl.rel(PlannerImpl.java:240)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-2054) Parser error on trivial UPDATE with dynamic parameters
[
https://issues.apache.org/jira/browse/CALCITE-2054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16254844#comment-16254844
]
Enrico Olivelli commented on CALCITE-2054:
--
The error is even with ProjectableFilterableTable
> Parser error on trivial UPDATE with dynamic parameters
> --
>
> Key: CALCITE-2054
> URL: https://issues.apache.org/jira/browse/CALCITE-2054
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.15.0
>Reporter: Enrico Olivelli
>Assignee: Julian Hyde
>
> with a simple UPDATE like:
> UPDATE mytable set a=? where b=?
> I get the error below.
> The "Table" is a ModifiableTable + ScannableTable, with "a" of type INTEGER
> and "b" of type VARCHAR
> Any hint ?
> Thank you
> Enrico
> {code}
> org.apache.calcite.runtime.CalciteContextException: At line 1, column 30:
> Illegal use of dynamic parameter
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:463)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:803)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:788)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:4651)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.inferUnknownTypes(SqlValidatorImpl.java:1694)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.inferUnknownTypes(SqlValidatorImpl.java:1769)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.expandSelectItem(SqlValidatorImpl.java:457)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.expandStar(SqlValidatorImpl.java:347)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectList(SqlToRelConverter.java:3709)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:663)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:620)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertUpdate(SqlToRelConverter.java:3398)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3048)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:556)
> at org.apache.calcite.prepare.PlannerImpl.rel(PlannerImpl.java:240)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-2054) Parser error on trivial UPDATE with dynamic parameters
[
https://issues.apache.org/jira/browse/CALCITE-2054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16254842#comment-16254842
]
Enrico Olivelli commented on CALCITE-2054:
--
[~julianhyde] Do you have time to take at look at this too? Thanks
> Parser error on trivial UPDATE with dynamic parameters
> --
>
> Key: CALCITE-2054
> URL: https://issues.apache.org/jira/browse/CALCITE-2054
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.15.0
>Reporter: Enrico Olivelli
>Assignee: Julian Hyde
>
> with a simple UPDATE like:
> UPDATE mytable set a=? where b=?
> I get the error below.
> The "Table" is a ModifiableTable + ScannableTable, with "a" of type INTEGER
> and "b" of type VARCHAR
> Any hint ?
> Thank you
> Enrico
> {code}
> org.apache.calcite.runtime.CalciteContextException: At line 1, column 30:
> Illegal use of dynamic parameter
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:463)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:803)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:788)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:4651)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.inferUnknownTypes(SqlValidatorImpl.java:1694)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.inferUnknownTypes(SqlValidatorImpl.java:1769)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.expandSelectItem(SqlValidatorImpl.java:457)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.expandStar(SqlValidatorImpl.java:347)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectList(SqlToRelConverter.java:3709)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:663)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:620)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertUpdate(SqlToRelConverter.java:3398)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3048)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:556)
> at org.apache.calcite.prepare.PlannerImpl.rel(PlannerImpl.java:240)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-2039) AssertionError when pushing project to ProjectableFilterableTable
[
https://issues.apache.org/jira/browse/CALCITE-2039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16254841#comment-16254841
]
Enrico Olivelli commented on CALCITE-2039:
--
Thank you so much.
Will give it a try soon.
> AssertionError when pushing project to ProjectableFilterableTable
> -
>
> Key: CALCITE-2039
> URL: https://issues.apache.org/jira/browse/CALCITE-2039
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.14.0
>Reporter: Alexey Roytman
>Assignee: Michael Mior
> Fix For: 1.15.0
>
> Attachments: CALCITE-2039.zip, PlannerExampleTest.java,
> PlannerExampleTest.java, calcite_2039_eclipse_project.zip
>
>
> When my table implements interface {{ProjectableFilterableTable}}, and I
> execute a query that contains column but also an expression, with assertions
> enabled ({{java -ea}}), I get an {{AssertionError}} at
> {{Mappings.create(Mappings.java:64)}}.
> The following query (notice the "select 0 as c1, ...")
> {code}
> select 0 as c1, D101.c1 as c3, D101.c2 as c4, D101.c3 as c5 from (
> select T101.Category as c1, T101.Revenue as c2,
> T101."YEAR" as c3 from (
> select "YEAR", Category, "MONTH", Territory, Quarter, Sub_Category,
> Age_Group, Gender, Country, Revenue, Num_Of_Orders, "DATE" from
> XSchema.HDP) T101) D101
> {code}
> causes an exception:
> {noformat}
> java.lang.AssertionError
> at org.apache.calcite.util.mapping.Mappings.create(Mappings.java:64)
> at org.apache.calcite.rel.core.Project.getMapping(Project.java:277)
> at org.apache.calcite.rel.core.Project.getMapping(Project.java:257)
> at
> org.apache.calcite.rel.rules.ProjectTableScanRule.apply(ProjectTableScanRule.java:100)
> at
> org.apache.calcite.rel.rules.ProjectTableScanRule$3.onMatch(ProjectTableScanRule.java:83)
> at
> org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:212)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:650)
> at org.apache.calcite.tools.Programs$5.run(Programs.java:326)
> at
> org.apache.calcite.tools.Programs$SequenceProgram.run(Programs.java:387)
> at org.apache.calcite.prepare.Prepare.optimize(Prepare.java:188)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:321)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:230)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:786)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:640)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:610)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:221)
> at
> org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:603)
> at
> org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:638)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:149)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:218)
> ...
> {noformat}
> In the Mappings.create(), mappingType is INVERSE_SURJECTION, and "assert
> sourceCount >= targetCount" throws the exception, because sourceCount is 3,
> and targetCount is 4.
> At the frame above, in Project.getMapping(), "projects" are: {{\[0, $1, $2,
> $0\]}} (1st is RexLiteral, others are RexInputRef). At the frame above, in
> EnumerableProject.getMapping(), getInput().getRowType() has only 3 fields in
> the table.
> I have a reproduction case (in Java) but it's not within a Calcite standard.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (CALCITE-2039) AssertionError at Mappings.create(Mappings.java:64) with "select 0 as c1,..." and TableProjectableFilterable
[
https://issues.apache.org/jira/browse/CALCITE-2039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Enrico Olivelli updated CALCITE-2039:
-
Attachment: PlannerExampleTest.java
attaching very simple reproducer
> AssertionError at Mappings.create(Mappings.java:64) with "select 0 as c1,..."
> and TableProjectableFilterable
>
>
> Key: CALCITE-2039
> URL: https://issues.apache.org/jira/browse/CALCITE-2039
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.14.0
>Reporter: Alexey Roytman
>Assignee: Michael Mior
> Attachments: CALCITE-2039.zip, PlannerExampleTest.java,
> PlannerExampleTest.java, calcite_2039_eclipse_project.zip
>
>
> When I use a ProjectableFilterableTable interface, the following query
> (notice the "select 0 as c1, ...")
> {code}
> select 0 as c1, D101.c1 as c3, D101.c2 as c4, D101.c3 as c5 from (
> select T101.Category as c1, T101.Revenue as c2,
> T101."YEAR" as c3 from (
> select "YEAR", Category, "MONTH", Territory, Quarter, Sub_Category,
> Age_Group, Gender, Country, Revenue, Num_Of_Orders, "DATE" from
> XSchema.HDP) T101) D101
> {code}
> causes an exception:
> {noformat}
> java.lang.AssertionError
> at org.apache.calcite.util.mapping.Mappings.create(Mappings.java:64)
> at org.apache.calcite.rel.core.Project.getMapping(Project.java:277)
> at org.apache.calcite.rel.core.Project.getMapping(Project.java:257)
> at
> org.apache.calcite.rel.rules.ProjectTableScanRule.apply(ProjectTableScanRule.java:100)
> at
> org.apache.calcite.rel.rules.ProjectTableScanRule$3.onMatch(ProjectTableScanRule.java:83)
> at
> org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:212)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:650)
> at org.apache.calcite.tools.Programs$5.run(Programs.java:326)
> at
> org.apache.calcite.tools.Programs$SequenceProgram.run(Programs.java:387)
> at org.apache.calcite.prepare.Prepare.optimize(Prepare.java:188)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:321)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:230)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:786)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:640)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:610)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:221)
> at
> org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:603)
> at
> org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:638)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:149)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:218)
> ...
> {noformat}
> In the Mappings.create(), mappingType is INVERSE_SURJECTION, and "assert
> sourceCount >= targetCount" throws the exception, because sourceCount is 3,
> and targetCount is 4.
> At the frame above, in Project.getMapping(), "projects" are: {{\[0, $1, $2,
> $0\]}} (1st is RexLiteral, others are RexInputRef). At the frame above, in
> EnumerableProject.getMapping(), getInput().getRowType() has only 3 fields in
> the table.
> I have a reproduction case (in Java) but it's not within a Calcite standard.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (CALCITE-2054) Parser error on trivial UPDATE with dynamic parameters
Enrico Olivelli created CALCITE-2054:
Summary: Parser error on trivial UPDATE with dynamic parameters
Key: CALCITE-2054
URL: https://issues.apache.org/jira/browse/CALCITE-2054
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.15.0
Reporter: Enrico Olivelli
Assignee: Julian Hyde
with a simple UPDATE like:
UPDATE mytable set a=? where b=?
I get the error below.
The "Table" is a ModifiableTable + ScannableTable, with "a" of type INTEGER and
"b" of type VARCHAR
Any hint ?
Thank you
Enrico
{code}
org.apache.calcite.runtime.CalciteContextException: At line 1, column 30:
Illegal use of dynamic parameter
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at
org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:463)
at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:803)
at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:788)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:4651)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.inferUnknownTypes(SqlValidatorImpl.java:1694)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.inferUnknownTypes(SqlValidatorImpl.java:1769)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.expandSelectItem(SqlValidatorImpl.java:457)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.expandStar(SqlValidatorImpl.java:347)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectList(SqlToRelConverter.java:3709)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:663)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:620)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertUpdate(SqlToRelConverter.java:3398)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3048)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:556)
at org.apache.calcite.prepare.PlannerImpl.rel(PlannerImpl.java:240)
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-2039) AssertionError at Mappings.create(Mappings.java:64) with "select 0 as c1,..." and TableProjectableFilterable
[
https://issues.apache.org/jira/browse/CALCITE-2039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16253405#comment-16253405
]
Enrico Olivelli commented on CALCITE-2039:
--
this is the plan
Query: UPDATE MYTABLE set id=7 where id=1
-- Logical Plan
LogicalTableModify(table=[[x, MYTABLE]], operation=[UPDATE],
updateColumnList=[[id]], sourceExpressionList=[[7]], flattened=[true])
LogicalProject(id=[$0], name=[$1], EXPR$0=[7])
LogicalFilter(condition=[=($0, 1)])
EnumerableTableScan(table=[[x, MYTABLE]])
-- Mid Plan
LogicalTableModify(subset=[rel#15:Subset#3.ENUMERABLE.any], table=[[x,
MYTABLE]], operation=[UPDATE], updateColumnList=[[id]],
sourceExpressionList=[[7]], flattened=[true])
LogicalProject(subset=[rel#12:Subset#2.NONE.any], id=[$0], name=[$1],
EXPR$0=[7])
LogicalFilter(subset=[rel#10:Subset#1.NONE.any], condition=[=($0, 1)])
EnumerableTableScan(subset=[rel#8:Subset#0.ENUMERABLE.any], table=[[x,
MYTABLE]])
> AssertionError at Mappings.create(Mappings.java:64) with "select 0 as c1,..."
> and TableProjectableFilterable
>
>
> Key: CALCITE-2039
> URL: https://issues.apache.org/jira/browse/CALCITE-2039
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.14.0
>Reporter: Alexey Roytman
>Assignee: Michael Mior
> Attachments: CALCITE-2039.zip, PlannerExampleTest.java,
> calcite_2039_eclipse_project.zip
>
>
> When I use a ProjectableFilterableTable interface, the following query
> (notice the "select 0 as c1, ...")
> {code}
> select 0 as c1, D101.c1 as c3, D101.c2 as c4, D101.c3 as c5 from (
> select T101.Category as c1, T101.Revenue as c2,
> T101."YEAR" as c3 from (
> select "YEAR", Category, "MONTH", Territory, Quarter, Sub_Category,
> Age_Group, Gender, Country, Revenue, Num_Of_Orders, "DATE" from
> XSchema.HDP) T101) D101
> {code}
> causes an exception:
> {noformat}
> java.lang.AssertionError
> at org.apache.calcite.util.mapping.Mappings.create(Mappings.java:64)
> at org.apache.calcite.rel.core.Project.getMapping(Project.java:277)
> at org.apache.calcite.rel.core.Project.getMapping(Project.java:257)
> at
> org.apache.calcite.rel.rules.ProjectTableScanRule.apply(ProjectTableScanRule.java:100)
> at
> org.apache.calcite.rel.rules.ProjectTableScanRule$3.onMatch(ProjectTableScanRule.java:83)
> at
> org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:212)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:650)
> at org.apache.calcite.tools.Programs$5.run(Programs.java:326)
> at
> org.apache.calcite.tools.Programs$SequenceProgram.run(Programs.java:387)
> at org.apache.calcite.prepare.Prepare.optimize(Prepare.java:188)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:321)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:230)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:786)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:640)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:610)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:221)
> at
> org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:603)
> at
> org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:638)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:149)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:218)
> ...
> {noformat}
> In the Mappings.create(), mappingType is INVERSE_SURJECTION, and "assert
> sourceCount >= targetCount" throws the exception, because sourceCount is 3,
> and targetCount is 4.
> At the frame above, in Project.getMapping(), "projects" are: {{\[0, $1, $2,
> $0\]}} (1st is RexLiteral, others are RexInputRef). At the frame above, in
> EnumerableProject.getMapping(), getInput().getRowType() has only 3 fields in
> the table.
> I have a reproduction case (in Java) but it's not within a Calcite standard.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (CALCITE-2039) AssertionError at Mappings.create(Mappings.java:64) with "select 0 as c1,..." and TableProjectableFilterable
[
https://issues.apache.org/jira/browse/CALCITE-2039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Enrico Olivelli updated CALCITE-2039:
-
Attachment: PlannerExampleTest.java
run using latest master
> AssertionError at Mappings.create(Mappings.java:64) with "select 0 as c1,..."
> and TableProjectableFilterable
>
>
> Key: CALCITE-2039
> URL: https://issues.apache.org/jira/browse/CALCITE-2039
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.14.0
>Reporter: Alexey Roytman
>Assignee: Michael Mior
> Attachments: CALCITE-2039.zip, PlannerExampleTest.java,
> calcite_2039_eclipse_project.zip
>
>
> When I use a ProjectableFilterableTable interface, the following query
> (notice the "select 0 as c1, ...")
> {code}
> select 0 as c1, D101.c1 as c3, D101.c2 as c4, D101.c3 as c5 from (
> select T101.Category as c1, T101.Revenue as c2,
> T101."YEAR" as c3 from (
> select "YEAR", Category, "MONTH", Territory, Quarter, Sub_Category,
> Age_Group, Gender, Country, Revenue, Num_Of_Orders, "DATE" from
> XSchema.HDP) T101) D101
> {code}
> causes an exception:
> {noformat}
> java.lang.AssertionError
> at org.apache.calcite.util.mapping.Mappings.create(Mappings.java:64)
> at org.apache.calcite.rel.core.Project.getMapping(Project.java:277)
> at org.apache.calcite.rel.core.Project.getMapping(Project.java:257)
> at
> org.apache.calcite.rel.rules.ProjectTableScanRule.apply(ProjectTableScanRule.java:100)
> at
> org.apache.calcite.rel.rules.ProjectTableScanRule$3.onMatch(ProjectTableScanRule.java:83)
> at
> org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:212)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:650)
> at org.apache.calcite.tools.Programs$5.run(Programs.java:326)
> at
> org.apache.calcite.tools.Programs$SequenceProgram.run(Programs.java:387)
> at org.apache.calcite.prepare.Prepare.optimize(Prepare.java:188)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:321)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:230)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:786)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:640)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:610)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:221)
> at
> org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:603)
> at
> org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:638)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:149)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:218)
> ...
> {noformat}
> In the Mappings.create(), mappingType is INVERSE_SURJECTION, and "assert
> sourceCount >= targetCount" throws the exception, because sourceCount is 3,
> and targetCount is 4.
> At the frame above, in Project.getMapping(), "projects" are: {{\[0, $1, $2,
> $0\]}} (1st is RexLiteral, others are RexInputRef). At the frame above, in
> EnumerableProject.getMapping(), getInput().getRowType() has only 3 fields in
> the table.
> I have a reproduction case (in Java) but it's not within a Calcite standard.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-2039) AssertionError at Mappings.create(Mappings.java:64) with "select 0 as c1,..." and TableProjectableFilterable
[
https://issues.apache.org/jira/browse/CALCITE-2039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16253400#comment-16253400
]
Enrico Olivelli commented on CALCITE-2039:
--
I am getting the same error, I have a simpler reproducer, I am attaching the
.java file, it is self contained
> AssertionError at Mappings.create(Mappings.java:64) with "select 0 as c1,..."
> and TableProjectableFilterable
>
>
> Key: CALCITE-2039
> URL: https://issues.apache.org/jira/browse/CALCITE-2039
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.14.0
>Reporter: Alexey Roytman
>Assignee: Michael Mior
> Attachments: CALCITE-2039.zip, calcite_2039_eclipse_project.zip
>
>
> When I use a ProjectableFilterableTable interface, the following query
> (notice the "select 0 as c1, ...")
> {code}
> select 0 as c1, D101.c1 as c3, D101.c2 as c4, D101.c3 as c5 from (
> select T101.Category as c1, T101.Revenue as c2,
> T101."YEAR" as c3 from (
> select "YEAR", Category, "MONTH", Territory, Quarter, Sub_Category,
> Age_Group, Gender, Country, Revenue, Num_Of_Orders, "DATE" from
> XSchema.HDP) T101) D101
> {code}
> causes an exception:
> {noformat}
> java.lang.AssertionError
> at org.apache.calcite.util.mapping.Mappings.create(Mappings.java:64)
> at org.apache.calcite.rel.core.Project.getMapping(Project.java:277)
> at org.apache.calcite.rel.core.Project.getMapping(Project.java:257)
> at
> org.apache.calcite.rel.rules.ProjectTableScanRule.apply(ProjectTableScanRule.java:100)
> at
> org.apache.calcite.rel.rules.ProjectTableScanRule$3.onMatch(ProjectTableScanRule.java:83)
> at
> org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:212)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:650)
> at org.apache.calcite.tools.Programs$5.run(Programs.java:326)
> at
> org.apache.calcite.tools.Programs$SequenceProgram.run(Programs.java:387)
> at org.apache.calcite.prepare.Prepare.optimize(Prepare.java:188)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:321)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:230)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:786)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:640)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:610)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:221)
> at
> org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:603)
> at
> org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:638)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:149)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:218)
> ...
> {noformat}
> In the Mappings.create(), mappingType is INVERSE_SURJECTION, and "assert
> sourceCount >= targetCount" throws the exception, because sourceCount is 3,
> and targetCount is 4.
> At the frame above, in Project.getMapping(), "projects" are: {{\[0, $1, $2,
> $0\]}} (1st is RexLiteral, others are RexInputRef). At the frame above, in
> EnumerableProject.getMapping(), getInput().getRowType() has only 3 fields in
> the table.
> I have a reproduction case (in Java) but it's not within a Calcite standard.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-2048) Create a better documentation for the Planner design
[ https://issues.apache.org/jira/browse/CALCITE-2048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250346#comment-16250346 ] Enrico Olivelli commented on CALCITE-2048: -- Maybe it would be useful a simple guide to plains explanations, like a showcase with a set of queries and for each query: - logical plan (after parse) - final plan (after findBestExp) - explanation of the RelNodes - variants based on : stats, Table implemented marker interfaces, conventions, TraitDefs, other important config (which I have not discovered yet) Javadocs in general seems well written, but a global introduction is the real gap > Create a better documentation for the Planner design > > > Key: CALCITE-2048 > URL: https://issues.apache.org/jira/browse/CALCITE-2048 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Edmon Begoli >Assignee: Edmon Begoli >Priority: Minor > Original Estimate: 672h > Remaining Estimate: 672h > > Per request of the development community, and the assessment that we need a > tutorial, documentation and example code to work directly with the planner, > because it is a lot harder to work with the planner than with an adapter. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
