[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-2039) AssertionError when pushing project to ProjectableFilterableTable
[
https://issues.apache.org/jira/browse/CALCITE-2039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16256260#comment-16256260
]
Julian Hyde commented on CALCITE-2039:
--
Sorry for gazumping you. When I saw a good test case I couldn't resist jumping
in.
> 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] [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=16256257#comment-16256257
]
Michael Mior commented on CALCITE-2039:
---
Thanks for sorting this one out [~julianhyde]! I was trying to get to the
bottom of this but you obviously had much more success :)
> 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] [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=16256255#comment-16256255
]
Julian Hyde commented on CALCITE-2054:
--
Sorry, I don't. Contributions welcome.
> 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-2058) Support JDK 10
[ https://issues.apache.org/jira/browse/CALCITE-2058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16256252#comment-16256252 ] Michael Mior commented on CALCITE-2058: --- I would suggest leaving this open. I wouldn't really want to consider JDK 10 supported if we're not regularly testing it. I don't think there's a big downside to not publicly claiming JDK 10 support anyway since it's unlikely many are wanting it yet. I'm not sure how complicated is to configure on Jenkins. It will be easy on Travis once the webupd8 PPA publishes a package for it. > Support JDK 10 > -- > > Key: CALCITE-2058 > URL: https://issues.apache.org/jira/browse/CALCITE-2058 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Julian Hyde > > JDK 10 is in early access right now, but it's never too soon. Let's make sure > that Calcite builds and runs on JDK 10, and add JDK 10 to the list of > supported versions in history.md. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-2057) StackOverflowError when running a JDBC query
[
https://issues.apache.org/jira/browse/CALCITE-2057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16256249#comment-16256249
]
Julian Hyde commented on CALCITE-2057:
--
This looks similar to CALCITE-1048, CALCITE-794, CALCITE-790. Maybe cycles in
the metadata evaluation due to cyclic RelNode graph, or maybe just a very deep
call stack.
> StackOverflowError when running a JDBC query
>
>
> Key: CALCITE-2057
> URL: https://issues.apache.org/jira/browse/CALCITE-2057
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.14.0
>Reporter: Eyal Segal
>Assignee: Julian Hyde
>Priority: Minor
>
> I've ran the following code:
> {code:java}
> try (ResultSet rs = statement.executeQuery(
> "SELECT p.name, r.views " +
> "FROM reports.a as r " +
> "INNER JOIN main.b as p ON p.id = CAST(r.p_id AS INT) AND
> p.id = 196 " +
> "WHERE p.id = 196 " +
> "AND r.p_id = 196 " +
> "AND r.data_timestamp = TIMESTAMP '2017-11-14 00:00:00'
> " )) {
> {code}
> And I'm getting the following StackOverflowError:
> {code:java}
> Exception in thread "main" java.lang.StackOverflowError
> at
> com.google.common.collect.ImmutableList.indexOf(ImmutableList.java:339)
> at GeneratedMetadataHandler_RowCount.getRowCount_$(Unknown Source)
> at GeneratedMetadataHandler_RowCount.getRowCount(Unknown Source)
> at
> org.apache.calcite.rel.metadata.RelMetadataQuery.getRowCount(RelMetadataQuery.java:235)
> at
> org.apache.calcite.rel.metadata.RelMdRowCount.getRowCount(RelMdRowCount.java:71)
> at GeneratedMetadataHandler_RowCount.getRowCount_$(Unknown Source)
> at GeneratedMetadataHandler_RowCount.getRowCount(Unknown Source)
> at
> org.apache.calcite.rel.metadata.RelMetadataQuery.getRowCount(RelMetadataQuery.java:235)
> at
> org.apache.calcite.rel.metadata.RelMdUtil.estimateFilteredRows(RelMdUtil.java:718)
> at
> org.apache.calcite.rel.metadata.RelMdRowCount.getRowCount(RelMdRowCount.java:123)
> at GeneratedMetadataHandler_RowCount.getRowCount_$(Unknown Source)
> at GeneratedMetadataHandler_RowCount.getRowCount(Unknown Source)
> at
> org.apache.calcite.rel.metadata.RelMetadataQuery.getRowCount(RelMetadataQuery.java:235)
> at
> org.apache.calcite.rel.metadata.RelMdRowCount.getRowCount(RelMdRowCount.java:71)
> at GeneratedMetadataHandler_RowCount.getRowCount_$(Unknown Source)
> at GeneratedMetadataHandler_RowCount.getRowCount(Unknown Source)
> at
> org.apache.calcite.rel.metadata.RelMetadataQuery.getRowCount(RelMetadataQuery.java:235)
> at
> org.apache.calcite.rel.metadata.RelMdUtil.estimateFilteredRows(RelMdUtil.java:718)
> at
> org.apache.calcite.rel.metadata.RelMdRowCount.getRowCount(RelMdRowCount.java:123)
> at GeneratedMetadataHandler_RowCount.getRowCount_$(Unknown Source)
> at GeneratedMetadataHandler_RowCount.getRowCount(Unknown Source)
> ...
> {code}
> It's solved by removing "AND p.id = 196" from the INNER JOIN, but it's still
> worth fixing.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (CALCITE-2057) StackOverflowError when running a JDBC query
[
https://issues.apache.org/jira/browse/CALCITE-2057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-2057:
-
Component/s: (was: build)
> StackOverflowError when running a JDBC query
>
>
> Key: CALCITE-2057
> URL: https://issues.apache.org/jira/browse/CALCITE-2057
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.14.0
>Reporter: Eyal Segal
>Assignee: Julian Hyde
>Priority: Minor
>
> I've ran the following code:
> {code:java}
> try (ResultSet rs = statement.executeQuery(
> "SELECT p.name, r.views " +
> "FROM reports.a as r " +
> "INNER JOIN main.b as p ON p.id = CAST(r.p_id AS INT) AND
> p.id = 196 " +
> "WHERE p.id = 196 " +
> "AND r.p_id = 196 " +
> "AND r.data_timestamp = TIMESTAMP '2017-11-14 00:00:00'
> " )) {
> {code}
> And I'm getting the following StackOverflowError:
> {code:java}
> Exception in thread "main" java.lang.StackOverflowError
> at
> com.google.common.collect.ImmutableList.indexOf(ImmutableList.java:339)
> at GeneratedMetadataHandler_RowCount.getRowCount_$(Unknown Source)
> at GeneratedMetadataHandler_RowCount.getRowCount(Unknown Source)
> at
> org.apache.calcite.rel.metadata.RelMetadataQuery.getRowCount(RelMetadataQuery.java:235)
> at
> org.apache.calcite.rel.metadata.RelMdRowCount.getRowCount(RelMdRowCount.java:71)
> at GeneratedMetadataHandler_RowCount.getRowCount_$(Unknown Source)
> at GeneratedMetadataHandler_RowCount.getRowCount(Unknown Source)
> at
> org.apache.calcite.rel.metadata.RelMetadataQuery.getRowCount(RelMetadataQuery.java:235)
> at
> org.apache.calcite.rel.metadata.RelMdUtil.estimateFilteredRows(RelMdUtil.java:718)
> at
> org.apache.calcite.rel.metadata.RelMdRowCount.getRowCount(RelMdRowCount.java:123)
> at GeneratedMetadataHandler_RowCount.getRowCount_$(Unknown Source)
> at GeneratedMetadataHandler_RowCount.getRowCount(Unknown Source)
> at
> org.apache.calcite.rel.metadata.RelMetadataQuery.getRowCount(RelMetadataQuery.java:235)
> at
> org.apache.calcite.rel.metadata.RelMdRowCount.getRowCount(RelMdRowCount.java:71)
> at GeneratedMetadataHandler_RowCount.getRowCount_$(Unknown Source)
> at GeneratedMetadataHandler_RowCount.getRowCount(Unknown Source)
> at
> org.apache.calcite.rel.metadata.RelMetadataQuery.getRowCount(RelMetadataQuery.java:235)
> at
> org.apache.calcite.rel.metadata.RelMdUtil.estimateFilteredRows(RelMdUtil.java:718)
> at
> org.apache.calcite.rel.metadata.RelMdRowCount.getRowCount(RelMdRowCount.java:123)
> at GeneratedMetadataHandler_RowCount.getRowCount_$(Unknown Source)
> at GeneratedMetadataHandler_RowCount.getRowCount(Unknown Source)
> ...
> {code}
> It's solved by removing "AND p.id = 196" from the INNER JOIN, but it's still
> worth fixing.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-2058) Support JDK 10
[ https://issues.apache.org/jira/browse/CALCITE-2058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16256241#comment-16256241 ] Julian Hyde commented on CALCITE-2058: -- [~elserj], [~michaelmior], Since you two have taken most interest in CI, I'd like your opinion: do you think we should get CI (either ASF or Travis) working under JDK 10 before we declare victory on this one? I have this working using the CI on my home server (build, test, verify, site) and I think that's probably enough for now. > Support JDK 10 > -- > > Key: CALCITE-2058 > URL: https://issues.apache.org/jira/browse/CALCITE-2058 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Julian Hyde > > JDK 10 is in early access right now, but it's never too soon. Let's make sure > that Calcite builds and runs on JDK 10, and add JDK 10 to the list of > supported versions in history.md. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-2045) Support "CREATE TYPE" DDL
[ https://issues.apache.org/jira/browse/CALCITE-2045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16256130#comment-16256130 ] Julian Hyde commented on CALCITE-2045: -- Definitely not part of CALCITE-707. You could wait until it goes in, or you could start developing in a branch based on a stable point in my branch, https://github.com/julianhyde/calcite/tree/707-ddl (for example, at https://github.com/julianhyde/calcite/commit/3b849a819a4470da3f91b31c242e80e29578df7d everything up to CREATE TABLE was working) and I'll help you rebase after 707 is committed. > Support "CREATE TYPE" DDL > - > > Key: CALCITE-2045 > URL: https://issues.apache.org/jira/browse/CALCITE-2045 > Project: Calcite > Issue Type: New Feature > Components: core >Reporter: Shuyi Chen >Assignee: Julian Hyde > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-2045) Support "CREATE TYPE" DDL
[ https://issues.apache.org/jira/browse/CALCITE-2045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16256078#comment-16256078 ] Shuyi Chen commented on CALCITE-2045: - Thanks, [~julianhyde]. I think that looks good to me as the first version. Are you planning to add it in Calcite-707 or we can implement it after it? > Support "CREATE TYPE" DDL > - > > Key: CALCITE-2045 > URL: https://issues.apache.org/jira/browse/CALCITE-2045 > Project: Calcite > Issue Type: New Feature > Components: core >Reporter: Shuyi Chen >Assignee: Julian Hyde > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (CALCITE-2016) ITEM + DOT operator does not work for array
[
https://issues.apache.org/jira/browse/CALCITE-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde resolved CALCITE-2016.
--
Resolution: Fixed
Fix Version/s: 1.15.0
Fixed in
[a3dd90f1|http://git-wip-us.apache.org/repos/asf/calcite/commit/a3dd90f1];
thanks for the PR, [~suez1224]!
In a [preceding
commit|http://git-wip-us.apache.org/repos/asf/calcite/commit/e8481e50] I added
a new method {{T SqlCallBinding.getOperandLiteralValue(int, Class)}}, which
makes it easier to get the string value of a character literal operand, and
refactored your code to use it.
> ITEM + DOT operator does not work for array
> ---
>
> Key: CALCITE-2016
> URL: https://issues.apache.org/jira/browse/CALCITE-2016
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Shuyi Chen
>Assignee: Julian Hyde
> Fix For: 1.15.0
>
>
> Query with ITEM + DOT operator for array does not parse. Below is an example
> query and its stack trace.
> *Query*: {code}SELECT employees[1].empno from dept_nested{code}
> *Stacktrace*:
> {noformat}
> java.lang.RuntimeException: Error while parsing query: SELECT
> employees[1].empno from dept_nested
> at
> org.apache.calcite.sql.test.SqlTesterImpl.parseAndValidate(SqlTesterImpl.java:161)
> at
> org.apache.calcite.sql.test.SqlTesterImpl.getResultType(SqlTesterImpl.java:148)
> at
> org.apache.calcite.sql.test.SqlTesterImpl.checkResultType(SqlTesterImpl.java:204)
> at
> org.apache.calcite.test.SqlValidatorTestCase$Sql.type(SqlValidatorTestCase.java:603)
> at
> org.apache.calcite.test.SqlValidatorTest.testRecordTypeElided(SqlValidatorTest.java:7715)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> 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:117)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:42)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:262)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:84)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
> Caused by: org.apache.calcite.sql.parser.SqlParseException: Encountered "."
> at line 1, column 20.
> Was expecting one of:
>
> "ORDER" ...
> "LIMIT" ...
> "OFFSET" ...
> "FETCH" ...
> "FROM" ...
> "," ...
> "AS" ...
> ...
> ...
> ...
> ...
> ...
> "UNION" ...
> "INTERSECT" ...
> "EXCEPT" ...
> "MINUS" ...
> "NOT" ...
> "IN" ...
> "BETWEEN" ...
> "LIKE" ...
> "SIMILAR" ...
> "=" ...
> ">" ...
> "<" ...
> "<=" ...
> ">=" ...
> "<>" ...
> "!=" ...
> "+" ...
> "-" ...
> "*" ...
> "/" ...
> "||" ...
> "AND" ...
> "OR" ...
> "IS" ...
> "MEMBER" ...
> "SUBMULTISET" ...
> "CONTAINS" ...
> "OVERLAPS"
[jira] [Commented] (CALCITE-2056) Limit/Offset in generated Sql does not work for many databases
[ https://issues.apache.org/jira/browse/CALCITE-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16255734#comment-16255734 ] Julian Hyde commented on CALCITE-2056: -- If you are interested in doing that work, that would be awesome. You should consider decomposing capability (can the database push down fetch? fetch+offset?) from syntax. I also believe in going deep: let's list which databases (and versions) we have certified against. There's little point implementing, say, Firebird's FIRST ... SKIP syntax if we can't handle other peculiarities of their SQL. > Limit/Offset in generated Sql does not work for many databases > -- > > Key: CALCITE-2056 > URL: https://issues.apache.org/jira/browse/CALCITE-2056 > Project: Calcite > Issue Type: Bug >Reporter: Luis Fernando Kauer >Assignee: Julian Hyde > > SqlDialect.supportsOffsetFetch() defines whether the dialect supports > OFFSET/FETCH clauses introduced by SQL:2008, and by default returns true. > SqlPrettyWriter.fetchOffset(SqlNode, SqlNode) uses that information to insert > "FETCH NEXT x ROWS" if it supportsOffsetFetch. > However, I noticed that many of the databases support it in different ways > and some do not support at all. > For example, Hsqldb, which is used in test cases does not accept FETCH NEXT x > ROWS, but it accepts LIMIT and FETCH FIRST x ROWS. > Some databases accept TOP x and others use something even different, but most > of them also accept LIMIT syntax. > I suggest we make using LIMIT the default, because it is the most accepted > and allow each SqlDialect do define its own way of using fetch and offset. > If we check how Hibernate sets the dialects to deal with limit/offset for > each database, we see that most use limit syntax and some use special syntax, > but very few are configured to use SQL 2008 syntax. > This hasn't been a problem until now because sort/limit/offset was not being > pushed to the database. But now that I'm trying to fix it, the generated SQL > is not working in Hsqldb. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-2056) Limit/Offset in generated Sql does not work for many databases
[ https://issues.apache.org/jira/browse/CALCITE-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16255259#comment-16255259 ] Luis Fernando Kauer commented on CALCITE-2056: -- I searched for how each database implements this and what I found is that very few implement SQL standard Offset/Fetch and only very recently, while most of them implement LIMIT/OFFSET. Some implement LIMIT (or FETCH) but not OFFSET: SELECT * FROM T LIMIT 10 OFFSET 20 Netezza, MySQL, Sybase, PostreSQL, SQLite, HSQLDB, H2, Vertica, Polyhedra, CouchBase, DB2, Vertica SELECT * FROM T LIMIT 10, 20 MySQL, DB2 SELECT * FROM T LIMIT 10 Netezza, MySQL, Sybase, PostreSQL, SQLite, HSQLDB, H2, Vertica, Polyhedra, CouchBase, DB2, Vertica, HIVE SELECT FIRST 10 * FROM T Ingres, Informix, Firebird SELECT TOP 10 * FROM T MsSQLServer, HSQLDB, MsAccess, Teradata SELECT FIRST 10 SKIP 20 * FROM T Firebird SELECT * FROM T FETCH FIRST 10 ROWS ONLY DB2, Oracle SELECT * FROM T OFFSET 20 ROWS FETCH NEXT 10 ROWS ONLY DB2(>=12), ORACLE(>12c), PostgreSQL(>8.4), HSQLDB(>2.2*), DERBY(>10.7) The HSQLDB version 2.3.1 used in Calcite does not accept this exact syntax, but it accepts SELECT * FROM T OFFSET 20 ROWS FETCH 10 ROWS ONLY. I think we should make Calcite work with any database and fallback to EnumerableLimit when limit/offset can't be pushed to the database. Some databases accept only limit but we could push the limit (with adjustment) and fallback the offset to Enumerable, when needed. We could have an enum of limit/offset variations, like NONE, LIMIT, LIMIT_OFFSET, FIRST, TOP, FETCH, FETCH_OFFSET, and each SqlDialect could return which one it implements. What do you think? > Limit/Offset in generated Sql does not work for many databases > -- > > Key: CALCITE-2056 > URL: https://issues.apache.org/jira/browse/CALCITE-2056 > Project: Calcite > Issue Type: Bug >Reporter: Luis Fernando Kauer >Assignee: Julian Hyde > > SqlDialect.supportsOffsetFetch() defines whether the dialect supports > OFFSET/FETCH clauses introduced by SQL:2008, and by default returns true. > SqlPrettyWriter.fetchOffset(SqlNode, SqlNode) uses that information to insert > "FETCH NEXT x ROWS" if it supportsOffsetFetch. > However, I noticed that many of the databases support it in different ways > and some do not support at all. > For example, Hsqldb, which is used in test cases does not accept FETCH NEXT x > ROWS, but it accepts LIMIT and FETCH FIRST x ROWS. > Some databases accept TOP x and others use something even different, but most > of them also accept LIMIT syntax. > I suggest we make using LIMIT the default, because it is the most accepted > and allow each SqlDialect do define its own way of using fetch and offset. > If we check how Hibernate sets the dialects to deal with limit/offset for > each database, we see that most use limit syntax and some use special syntax, > but very few are configured to use SQL 2008 syntax. > This hasn't been a problem until now because sort/limit/offset was not being > pushed to the database. But now that I'm trying to fix it, the generated SQL > is not working in Hsqldb. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-2055) Check year, month, day, hour, minute and second ranges for date and time literals
[
https://issues.apache.org/jira/browse/CALCITE-2055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16255139#comment-16255139
]
Volodymyr Vysotskyi commented on CALCITE-2055:
--
[~julianhyde], thanks for the review, I have changed commit message, Jira and
pull request titles; replaced {{AssertionError}} by
{{IllegalArgumentException}}; modified unit tests to call {{fail()}} instead of
throwing the exception from the catch block. Could you please take a look again?
> Check year, month, day, hour, minute and second ranges for date and time
> literals
> -
>
> Key: CALCITE-2055
> URL: https://issues.apache.org/jira/browse/CALCITE-2055
> Project: Calcite
> Issue Type: Bug
>Reporter: Volodymyr Vysotskyi
>Assignee: Julian Hyde
>
> Currently, if the year that is passed into {{DateString}} constructor has
> five digits, the first digit is trimmed. This trimming happens in the
> {{DateTimeStringUtils.int4()}} method:
> {code:sql}
> private static void int4(StringBuilder buf, int i) {
> buf.append((char) ('0' + (i / 1000) % 10));
> buf.append((char) ('0' + (i / 100) % 10));
> buf.append((char) ('0' + (i / 10) % 10));
> buf.append((char) ('0' + i % 10));
> }
> {code}
> The same problem with month and day values.
> Instead of trimming the value, the correct behaviour is to throw an exception
> if any of the values are outside the expected range.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (CALCITE-2055) Check year, month, day, hour, minute and second ranges for date and time literals
[
https://issues.apache.org/jira/browse/CALCITE-2055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Volodymyr Vysotskyi updated CALCITE-2055:
-
Summary: Check year, month, day, hour, minute and second ranges for date
and time literals (was: Add check for year/month/day range)
> Check year, month, day, hour, minute and second ranges for date and time
> literals
> -
>
> Key: CALCITE-2055
> URL: https://issues.apache.org/jira/browse/CALCITE-2055
> Project: Calcite
> Issue Type: Bug
>Reporter: Volodymyr Vysotskyi
>Assignee: Julian Hyde
>
> Currently, if the year that is passed into {{DateString}} constructor has
> five digits, the first digit is trimmed. This trimming happens in the
> {{DateTimeStringUtils.int4()}} method:
> {code:sql}
> private static void int4(StringBuilder buf, int i) {
> buf.append((char) ('0' + (i / 1000) % 10));
> buf.append((char) ('0' + (i / 100) % 10));
> buf.append((char) ('0' + (i / 10) % 10));
> buf.append((char) ('0' + i % 10));
> }
> {code}
> The same problem with month and day values.
> Instead of trimming the value, the correct behaviour is to throw an exception
> if any of the values are outside the expected range.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (CALCITE-2057) StackOverflowError when running a JDBC query
Eyal Segal created CALCITE-2057:
---
Summary: StackOverflowError when running a JDBC query
Key: CALCITE-2057
URL: https://issues.apache.org/jira/browse/CALCITE-2057
Project: Calcite
Issue Type: Bug
Components: build
Affects Versions: 1.14.0
Reporter: Eyal Segal
Assignee: Julian Hyde
Priority: Minor
I've ran the following code:
{code:java}
try (ResultSet rs = statement.executeQuery(
"SELECT p.name, r.views " +
"FROM reports.a as r " +
"INNER JOIN main.b as p ON p.id = CAST(r.p_id AS INT) AND
p.id = 196 " +
"WHERE p.id = 196 " +
"AND r.p_id = 196 " +
"AND r.data_timestamp = TIMESTAMP '2017-11-14 00:00:00' "
)) {
{code}
And I'm getting the following StackOverflowError:
{code:java}
Exception in thread "main" java.lang.StackOverflowError
at
com.google.common.collect.ImmutableList.indexOf(ImmutableList.java:339)
at GeneratedMetadataHandler_RowCount.getRowCount_$(Unknown Source)
at GeneratedMetadataHandler_RowCount.getRowCount(Unknown Source)
at
org.apache.calcite.rel.metadata.RelMetadataQuery.getRowCount(RelMetadataQuery.java:235)
at
org.apache.calcite.rel.metadata.RelMdRowCount.getRowCount(RelMdRowCount.java:71)
at GeneratedMetadataHandler_RowCount.getRowCount_$(Unknown Source)
at GeneratedMetadataHandler_RowCount.getRowCount(Unknown Source)
at
org.apache.calcite.rel.metadata.RelMetadataQuery.getRowCount(RelMetadataQuery.java:235)
at
org.apache.calcite.rel.metadata.RelMdUtil.estimateFilteredRows(RelMdUtil.java:718)
at
org.apache.calcite.rel.metadata.RelMdRowCount.getRowCount(RelMdRowCount.java:123)
at GeneratedMetadataHandler_RowCount.getRowCount_$(Unknown Source)
at GeneratedMetadataHandler_RowCount.getRowCount(Unknown Source)
at
org.apache.calcite.rel.metadata.RelMetadataQuery.getRowCount(RelMetadataQuery.java:235)
at
org.apache.calcite.rel.metadata.RelMdRowCount.getRowCount(RelMdRowCount.java:71)
at GeneratedMetadataHandler_RowCount.getRowCount_$(Unknown Source)
at GeneratedMetadataHandler_RowCount.getRowCount(Unknown Source)
at
org.apache.calcite.rel.metadata.RelMetadataQuery.getRowCount(RelMetadataQuery.java:235)
at
org.apache.calcite.rel.metadata.RelMdUtil.estimateFilteredRows(RelMdUtil.java:718)
at
org.apache.calcite.rel.metadata.RelMdRowCount.getRowCount(RelMdRowCount.java:123)
at GeneratedMetadataHandler_RowCount.getRowCount_$(Unknown Source)
at GeneratedMetadataHandler_RowCount.getRowCount(Unknown Source)
...
{code}
It's solved by removing "AND p.id = 196" from the INNER JOIN, but it's still
worth fixing.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
