[jira] [Commented] (CALCITE-2641) DATE and TIMESTAMP arguments to user-defined table function
[
https://issues.apache.org/jira/browse/CALCITE-2641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16735187#comment-16735187
]
Piotr Bojko commented on CALCITE-2641:
--
[~vladimirsitnikov] yeah - the PR 900 was created just a day or more before we
have a talk about it on emails.
See:
{noformat}
Vladimir Sitnikov sitnikov.vladi...@gmail.com via calcite.apache.org
Nov 6, 2018, 3:35 PM
to Apache
I don't mean to fire a Volcano rule.
I mean to just reuse the code in a creative way for the purpose of
SqlUserDefinedTableMacro.coerce
Currently, SqlUserDefinedTableMacro.coerce knows certain hard-coded cases,
however it would probably be better if the conversion could be just reused
from already existing in Calcite code.
{noformat}
Since then I have found more important things on calcite and this one was
queued on my spare time.
> DATE and TIMESTAMP arguments to user-defined table function
> ---
>
> Key: CALCITE-2641
> URL: https://issues.apache.org/jira/browse/CALCITE-2641
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0, 1.18.0
>Reporter: Piotr Bojko
>Assignee: Julian Hyde
>Priority: Major
>
> I am trying to create UDF with java.sql.Timestamp as a parameter:
> {code:java}
> public static QueryableTable getTable(
> @Parameter(name = "Projection") String projection,
> @Parameter(name = "Query") String query,
> @Parameter(name = "Test Timestamp") Timestamp
> timestamp)
> {code}
> But when using following UDF like this:
> {code:java}
> SELECT * FROM TABLE(MYUDF('ID','', TIMESTAMP '2013-01-01 01:01:01'))
> {code}
> I've got following exception and wondering whether I am missing something or
> having date/time as a parameter is not fully supported yet?
> {noformat}
> [INFO] [talledLocalContainer] java.lang.AssertionError: value 2013-01-01
> 01:01:01 does not match type class java.sql.Timestamp
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.ConstantExpression.(ConstantExpression.java:49)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.Expressions.constant(Expressions.java:588)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.OptimizeShuttle.visit(OptimizeShuttle.java:278)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.UnaryExpression.accept(UnaryExpression.java:37)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.GotoStatement.accept(GotoStatement.java:60)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.BlockBuilder.optimize(BlockBuilder.java:438)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.BlockBuilder.toBlock(BlockBuilder.java:322)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlUserDefinedTableMacro.coerce(SqlUserDefinedTableMacro.java:190)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlUserDefinedTableMacro.convertArguments(SqlUserDefinedTableMacro.java:110)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlUserDefinedTableFunction.getRowType(SqlUserDefinedTableFunction.java:70)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.ProcedureNamespace.validateImpl(ProcedureNamespace.java:62)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:971)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:950)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateFrom(SqlValidatorImpl.java:3036)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateFrom(SqlValidatorImpl.java:3018)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3288)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:60)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:971)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:950)
> [INFO] [talledLocalContainer]
[jira] [Commented] (CALCITE-2742) Update RexImpTable to user DataContext to retrieve USER and SYSTEM_USER
[ https://issues.apache.org/jira/browse/CALCITE-2742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16722316#comment-16722316 ] Piotr Bojko commented on CALCITE-2742: -- Hello, I have partly implemented this on CALCITE-2194. > Update RexImpTable to user DataContext to retrieve USER and SYSTEM_USER > --- > > Key: CALCITE-2742 > URL: https://issues.apache.org/jira/browse/CALCITE-2742 > Project: Calcite > Issue Type: Improvement >Reporter: Jacques Nadeau >Assignee: Jacques Nadeau >Priority: Major > > Right now, USER and SYSTEM_USER are hardcoded to "sa" and the system property > of user.name. Let's update them to use the DataContext system like the other > similar types of values. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2697) Better handling bindable params pushed down to JDBC schema
[ https://issues.apache.org/jira/browse/CALCITE-2697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16714650#comment-16714650 ] Piotr Bojko commented on CALCITE-2697: -- I have changed a type of the ticket because for some types - calcite mishandles now setting up a parameters on jdbc statement. Appropriate test is included. > Better handling bindable params pushed down to JDBC schema > -- > > Key: CALCITE-2697 > URL: https://issues.apache.org/jira/browse/CALCITE-2697 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: Piotr Bojko >Assignee: Julian Hyde >Priority: Major > > This is a follow up for CALCITE-563 . > Current DataContext has insufficient info about original bind param value and > type setup by an end user. > I would go with enriching DataContext with more information from TypedValue > wrappers for params. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2697) Better handling bindable params pushed down to JDBC schema
[ https://issues.apache.org/jira/browse/CALCITE-2697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Piotr Bojko updated CALCITE-2697: - Issue Type: Bug (was: Improvement) > Better handling bindable params pushed down to JDBC schema > -- > > Key: CALCITE-2697 > URL: https://issues.apache.org/jira/browse/CALCITE-2697 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: Piotr Bojko >Assignee: Julian Hyde >Priority: Major > > This is a follow up for CALCITE-563 . > Current DataContext has insufficient info about original bind param value and > type setup by an end user. > I would go with enriching DataContext with more information from TypedValue > wrappers for params. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (CALCITE-2697) Better handling bindable params pushed down to JDBC schema
[ https://issues.apache.org/jira/browse/CALCITE-2697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Piotr Bojko reassigned CALCITE-2697: Assignee: Julian Hyde (was: Piotr Bojko) I have created a pull for this. https://github.com/apache/calcite/pull/963 > Better handling bindable params pushed down to JDBC schema > -- > > Key: CALCITE-2697 > URL: https://issues.apache.org/jira/browse/CALCITE-2697 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Piotr Bojko >Assignee: Julian Hyde >Priority: Major > > This is a follow up for CALCITE-563 . > Current DataContext has insufficient info about original bind param value and > type setup by an end user. > I would go with enriching DataContext with more information from TypedValue > wrappers for params. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2719) MySQL does not support cast to bigint type
[ https://issues.apache.org/jira/browse/CALCITE-2719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16706975#comment-16706975 ] Piotr Bojko commented on CALCITE-2719: -- I've pushed the suggested change for CAST to INTEGER > MySQL does not support cast to bigint type > -- > > Key: CALCITE-2719 > URL: https://issues.apache.org/jira/browse/CALCITE-2719 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.17.0 >Reporter: Piotr Bojko >Assignee: Julian Hyde >Priority: Major > > Cast to BIGING is not supported in MySQL. The trick is to use CAST to SIGNED > INT. > When accepted I will try to fix this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2719) MySQL does not support cast to bigint type
[ https://issues.apache.org/jira/browse/CALCITE-2719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16706859#comment-16706859 ] Piotr Bojko edited comment on CALCITE-2719 at 12/3/18 9:16 AM: --- [~julianhyde] I am afraid MySQL - as far I have read the docs - does not support any casting to explicite 32 bit integer. I would go with CAST to SIGNED for INTEGER - this would be still a step further from current implementation. Then I would log following issues: # CAST to INTEGER when pushed to MySQL can produce overflow (bug, now it is similar but with signed/unsigned values) # Escaping to alien built in data types is based on hardcoding uderscore in an identifier (bug/improvement) was (Author: ptrbojko): [~julianhyde] I am afraid MySQL - as far I have read the docs - does not support any casting to explicite 32 bit integer. I would go with CAST to SIGNED for INTEGER - this would be still a step further from current implementation. The I would log to issues: # CAST to INTEGER when pushed to MySQL can produce overflow (bug, now it is similar but with signed/unsigned values) # Escaping to alien built in data types is based on hardcoding uderscore in an identifier (bug/improvement) > MySQL does not support cast to bigint type > -- > > Key: CALCITE-2719 > URL: https://issues.apache.org/jira/browse/CALCITE-2719 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.17.0 >Reporter: Piotr Bojko >Assignee: Julian Hyde >Priority: Major > > Cast to BIGING is not supported in MySQL. The trick is to use CAST to SIGNED > INT. > When accepted I will try to fix this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2719) MySQL does not support cast to bigint type
[ https://issues.apache.org/jira/browse/CALCITE-2719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16706859#comment-16706859 ] Piotr Bojko edited comment on CALCITE-2719 at 12/3/18 9:16 AM: --- [~julianhyde] I am afraid MySQL - as far I have read the docs - does not support any casting to explicite 32 bit integer. I would go with CAST to SIGNED for INTEGER - this would be still a step further from current implementation. The I would log to issues: # CAST to INTEGER when pushed to MySQL can produce overflow (bug, now it is similar but with signed/unsigned values) # Escaping to alien built in data types is based on hardcoding uderscore in an identifier (bug/improvement) was (Author: ptrbojko): [~julianhyde] I am afraid MySQL - as far I have read the docs - does not support any casting to explicite 32 bit integer. I would go with CAST to SIGNED for INTEGER - this would be still a step further from current. The I would log to issues: # CAST to INTEGER when pushed to MySQL can produce overflow (bug, now it is similar but with signed/unsigned values) # Escaping to alien built in data types is based on hardcoding uderscore in an identifier (bug/improvement) > MySQL does not support cast to bigint type > -- > > Key: CALCITE-2719 > URL: https://issues.apache.org/jira/browse/CALCITE-2719 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.17.0 >Reporter: Piotr Bojko >Assignee: Julian Hyde >Priority: Major > > Cast to BIGING is not supported in MySQL. The trick is to use CAST to SIGNED > INT. > When accepted I will try to fix this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2719) MySQL does not support cast to bigint type
[ https://issues.apache.org/jira/browse/CALCITE-2719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16706859#comment-16706859 ] Piotr Bojko commented on CALCITE-2719: -- [~julianhyde] I am afraid MySQL - as far I have read the docs - does not support any casting to explicite 32 bit integer. I would go with CAST to SIGNED for INTEGER - this would be still a step further from current. The I would log to issues: # CAST to INTEGER when pushed to MySQL can produce overflow (bug, now it is similar but with signed/unsigned values) # Escaping to alien built in data types is based on hardcoding uderscore in an identifier (bug/improvement) > MySQL does not support cast to bigint type > -- > > Key: CALCITE-2719 > URL: https://issues.apache.org/jira/browse/CALCITE-2719 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.17.0 >Reporter: Piotr Bojko >Assignee: Julian Hyde >Priority: Major > > Cast to BIGING is not supported in MySQL. The trick is to use CAST to SIGNED > INT. > When accepted I will try to fix this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2719) MySQL does not support cast to bigint type
[ https://issues.apache.org/jira/browse/CALCITE-2719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Piotr Bojko updated CALCITE-2719: - Description: Cast to BIGING is not supported in MySQL. The trick is to use CAST to SIGNED INT. When accepted I will try to fix this. was: Cast to BIGING is not supported in MySQL. The trick is to use CAST to UNSIGNED INT. When accepted I will try to fix this. > MySQL does not support cast to bigint type > -- > > Key: CALCITE-2719 > URL: https://issues.apache.org/jira/browse/CALCITE-2719 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.17.0 >Reporter: Piotr Bojko >Assignee: Julian Hyde >Priority: Major > > Cast to BIGING is not supported in MySQL. The trick is to use CAST to SIGNED > INT. > When accepted I will try to fix this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2719) MySQL does not support cast to bigint type
[ https://issues.apache.org/jira/browse/CALCITE-2719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16706490#comment-16706490 ] Piotr Bojko commented on CALCITE-2719: -- Here is a pull - https://github.com/apache/calcite/pull/953 I've come to conclusion that CAST to INTEGER which is already customized in MySQL should be converted to CAST to SIGNED in MySQL, same as for this case. However - now conversion (for INTEGER) goes to UNSIGNED. History for the MySqlDialect tells nothing about that. Should we also change CAST to INTEGER ? > MySQL does not support cast to bigint type > -- > > Key: CALCITE-2719 > URL: https://issues.apache.org/jira/browse/CALCITE-2719 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.17.0 >Reporter: Piotr Bojko >Assignee: Julian Hyde >Priority: Major > > Cast to BIGING is not supported in MySQL. The trick is to use CAST to > UNSIGNED INT. > When accepted I will try to fix this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2719) MySQL does not support cast to bigint type
[ https://issues.apache.org/jira/browse/CALCITE-2719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Piotr Bojko updated CALCITE-2719: - Description: Cast to BIGING is not supported in MySQL. The trick is to use CAST to UNSIGNED INT. When accepted I will try to fix this. > MySQL does not support cast to bigint type > -- > > Key: CALCITE-2719 > URL: https://issues.apache.org/jira/browse/CALCITE-2719 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.17.0 >Reporter: Piotr Bojko >Assignee: Julian Hyde >Priority: Major > > Cast to BIGING is not supported in MySQL. The trick is to use CAST to > UNSIGNED INT. > When accepted I will try to fix this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2715) MS SQL Server does not support character set as part of data type
[ https://issues.apache.org/jira/browse/CALCITE-2715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16703195#comment-16703195 ] Piotr Bojko commented on CALCITE-2715: -- I have added a test case. I haven't really checked NVARCHAR, albeit CHARACTER SET is still not supported here. > MS SQL Server does not support character set as part of data type > - > > Key: CALCITE-2715 > URL: https://issues.apache.org/jira/browse/CALCITE-2715 > Project: Calcite > Issue Type: Bug >Reporter: Piotr Bojko >Assignee: Julian Hyde >Priority: Major > > MS SQL Server does not support character set as part of data type, see > https://docs.microsoft.com/en-us/sql/t-sql/data-types/char-and-varchar-transact-sql?view=sql-server-2017 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-2719) MySQL does not support cast to bigint type
Piotr Bojko created CALCITE-2719: Summary: MySQL does not support cast to bigint type Key: CALCITE-2719 URL: https://issues.apache.org/jira/browse/CALCITE-2719 Project: Calcite Issue Type: Bug Components: core Affects Versions: 1.17.0 Reporter: Piotr Bojko Assignee: Julian Hyde -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2715) MS SQL Server does not support character set as part of data type
[ https://issues.apache.org/jira/browse/CALCITE-2715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16701729#comment-16701729 ] Piotr Bojko commented on CALCITE-2715: -- Here is a pull https://github.com/apache/calcite/pull/945 > MS SQL Server does not support character set as part of data type > - > > Key: CALCITE-2715 > URL: https://issues.apache.org/jira/browse/CALCITE-2715 > Project: Calcite > Issue Type: Bug >Reporter: Piotr Bojko >Assignee: Julian Hyde >Priority: Major > > MS SQL Server does not support character set as part of data type, see > https://docs.microsoft.com/en-us/sql/t-sql/data-types/char-and-varchar-transact-sql?view=sql-server-2017 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2667) sql2rel fails on join between table function and other table
[
https://issues.apache.org/jira/browse/CALCITE-2667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16695970#comment-16695970
]
Piotr Bojko commented on CALCITE-2667:
--
[~julianhyde], as for the your first comment (this one with 2667-join-udtf) - I
think this is similar to my "Solution 1". It has some flaws. See below:
Before state:
OriginalJoin:
- OriginalProjectA(OriginalA fields)
- OriginalProjectB(OriginalB fields)
Leaves.contains(OriginalProjectA, OriginalProjectB)
After state:
NewJoin
- NewProjectA(OriginalA + NewA fields)
- NewProjectB(OriginalB + NewB fields)
Leaves.contains(NewProjectA, NewProjectB)
First flaw is that in the rel tree you could still have a OriginalA or
OriginalB project and this they should still be then in Leaves.
Second flaw is much major. SqlToRelConverter navigates through inputs to find
an sqlidentifier using offsets. It does this only on leaves found in inputs and
their subtrees in an order (left to right). When finding an SqlIdentifier in
NewProjectB - the offset is not valid when projecting it to current inputs - it
will be shifted at least NewA fields. This is why I have implemented in
solution 1 a projection of found offset onto inputs. However the logic was
pretty naive.
I think you follow the same thinking us me, because 2667-join-udtf-2 is a
variation of my solution 2 but more precise.
Am I right? If yes I will follow the 2667-join-udtf-2 and ship the pull in
incoming days.
> sql2rel fails on join between table function and other table
>
>
> Key: CALCITE-2667
> URL: https://issues.apache.org/jira/browse/CALCITE-2667
> Project: Calcite
> Issue Type: Bug
>Reporter: Piotr Bojko
>Assignee: Julian Hyde
>Priority: Major
>
> Bug reproduction is here -
> https://github.com/ptrbojko/calcite/tree/bug/CALCITE-2667
> {noformat}
> > java.lang.AssertionError: Field ordinal 2 is invalid for type
> > 'RecordType(VARCHAR TYPE, VARCHAR CODEVALUE)'
> > at
> > org.apache.calcite.rex.RexBuilder.makeFieldAccess(RexBuilder.java:188)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.convertIdentifier(SqlToRelConverter.java:3616)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.access$2100(SqlToRelConverter.java:215)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:4691)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:3987)
> > at org.apache.calcite.sql.SqlIdentifier.accept(SqlIdentifier.java:334)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:4551)
> > at
> > org.apache.calcite.sql2rel.StandardConvertletTable.lambda$new$9(StandardConvertletTable.java:204)
> > at
> > org.apache.calcite.sql2rel.SqlNodeToRexConverterImpl.convertCall(SqlNodeToRexConverterImpl.java:63)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:4682)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:3987)
> > at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:138)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:4551)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectList(SqlToRelConverter.java:3830)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:668)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:625)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3074)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:561)
> > at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:265)
> > at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:231)
> > at
> > org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:772)
> > at
> > org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:636)
> > at
> > org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:606)
> > at
> > org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:229)
> > at
> > org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:550)
> > at
> > org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:675)
> > at
> > org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:156)
> > at
> > org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:227)
> >
[jira] [Created] (CALCITE-2697) Better handling bindable params pushed down to JDBC schema
Piotr Bojko created CALCITE-2697: Summary: Better handling bindable params pushed down to JDBC schema Key: CALCITE-2697 URL: https://issues.apache.org/jira/browse/CALCITE-2697 Project: Calcite Issue Type: Improvement Components: core Reporter: Piotr Bojko Assignee: Piotr Bojko This is a follow up for CALCITE-563 . Current DataContext has insufficient info about original bind param value and type setup by an end user. I would go with enriching DataContext with more information from TypedValue wrappers for params. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2667) sql2rel fails on join between table function and other table
[ https://issues.apache.org/jira/browse/CALCITE-2667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16694642#comment-16694642 ] Piotr Bojko edited comment on CALCITE-2667 at 11/21/18 1:24 PM: I have found two solutions *Solution 1* This one is based on assumption that SqlToRelConverter.leaves are out of sync with a relational tree when RelBuilder pushes down join conditions (RelOptUtil.pushDownJoinConditions). In such case left or/and right inputs of a join could be merged into new projects. The solution was to resync SqlToRelConverter.leaves with a new merged project. But with this approach next problem occured. As in my previous comment - SqlToRelConverter.convertIdentifier assumes that looking for an identifier through inputs based on an offset is the same as looking through union of inputs and leaves. Such assumption is not correct when in a relational tree would be a project with permutation in its expressions - such case can occur when new merged projects is synced! I have changed this logic a little bit - now identifier is being search through union of inputs and leaves and projected on to inputs (offset is being recalculated to match the proper coordinates in the inputs). However I've come to conclusion that my implementation (the second part) is a little bit naive and it takes only RexInputRefs into consideration when recalculated offset for inputs. Such prototype I've pushed into https://github.com/ptrbojko/calcite/tree/bug/CALCITE-2667 with an example of one failing tests showing RexInputRefs is not enough. *Side note* - I think that SqlToRelConverter.convertIdentifier is very fragile because of the mentioned assumption in its logic. In my honest opinion it should be rewritten, maybe as the proposed approach. The whole concept of leaves is very fragile on its own - leaves can vanished from the rel tree because of optimization or other future changes and there is no mechanism to prevent this. See https://github.com/ptrbojko/calcite/tree/bug/CALCITE-2667 for details. *Solution 2* This one is based on assumption that we should prevent merging projects in RelOptUtil.pushDownJoinConditions when merged projects is a leaf in SqlToRelConverter. I've extended then RelBuilder to be configurable and SqlToRelConverter enriching RelBuilder with a check if a project is not a leaf and can be merged. This solution alters expected relational tree. I had to tune some tests which were checking expected plans, because of missing merge. Pull request is here - https://github.com/apache/calcite/pull/931 *Side note*: I've choosed the second approach because it does not alter any assumptions and was less invasive. The first one must be validated by a party more familiar with a SqlToRelConverter. was (Author: ptrbojko): I have found two solutions *Solution 1* This one is based on assumption that SqlToRelConverter.leaves are out of sync with a relational tree when RelBuilder pushes down join conditions (RelOptUtil.pushDownJoinConditions). In such case left or/and right inputs of a join could be merged into new projects. The solution was to resync SqlToRelConverter.leaves with a new merged project. But with this approach next problem occured. As in my previous comment - SqlToRelConverter.convertIdentifier assumes that looking an identifier through inputs based on an offset is the same as looking mentioned through union of inputs and leaves. Such assumption is not correct when in a relational tree would be a project with permutation in its expressions - such case can occur when new merged projects is synced! I have changed this logic a little bit - now identifier is being search through union of inputs and leaves and projected on to inputs (offset is being recalculated to match the proper coordinates in the inputs). However I've come to conclusion that my implementation (the second part) is a little bit naive and it takes only RexInputRefs into consideration when recalculated offset for inputs. Such prototype I've pushed into https://github.com/ptrbojko/calcite/tree/bug/CALCITE-2667 with an example of one failing tests showing RexInputRefs are not enough. *Side note* - I think that SqlToRelConverter.convertIdentifier is very fragile because of the mentioned assumption in its logic. In my honest opinion it should be rewritten, maybe as the proposed approach. See https://github.com/ptrbojko/calcite/tree/bug/CALCITE-2667 for details. *Solution 2* This one is based on assumption that we should prevent merging projects in RelOptUtil.pushDownJoinConditions when merged projects is a leaf in SqlToRelConverter. I've extended then RelBuilder to be configurable and SqlToRelConverter enriching RelBuilder with a check if a project is not a leaf and can be merged. This solution alters expected relational tree. I had to tune some tests which were checking
[jira] [Commented] (CALCITE-2667) sql2rel fails on join between table function and other table
[
https://issues.apache.org/jira/browse/CALCITE-2667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16694642#comment-16694642
]
Piotr Bojko commented on CALCITE-2667:
--
I have found two solutions
*Solution 1*
This one is based on assumption that SqlToRelConverter.leaves are out of sync
with a relational tree when RelBuilder pushes down join conditions
(RelOptUtil.pushDownJoinConditions). In such case left or/and right inputs of a
join could be merged into new projects.
The solution was to resync SqlToRelConverter.leaves with a new merged project.
But with this approach next problem occured. As in my previous comment -
SqlToRelConverter.convertIdentifier assumes that looking an identifier through
inputs based on an offset is the same as looking mentioned through union of
inputs and leaves. Such assumption is not correct when in a relational tree
would be a project with permutation in its expressions - such case can occur
when new merged projects is synced! I have changed this logic a little bit -
now identifier is being search through union of inputs and leaves and projected
on to inputs (offset is being recalculated to match the proper coordinates in
the inputs).
However I've come to conclusion that my implementation (the second part) is a
little bit naive and it takes only RexInputRefs into consideration when
recalculated offset for inputs. Such prototype I've pushed into
https://github.com/ptrbojko/calcite/tree/bug/CALCITE-2667 with an example of
one failing tests showing RexInputRefs are not enough.
*Side note* - I think that SqlToRelConverter.convertIdentifier is very fragile
because of the mentioned assumption in its logic. In my honest opinion it
should be rewritten, maybe as the proposed approach.
See https://github.com/ptrbojko/calcite/tree/bug/CALCITE-2667 for details.
*Solution 2*
This one is based on assumption that we should prevent merging projects in
RelOptUtil.pushDownJoinConditions when merged projects is a leaf in
SqlToRelConverter. I've extended then RelBuilder to be configurable and
SqlToRelConverter enriching RelBuilder with a check if a project is not a leaf
and can be merged.
This solution alters expected relational tree. I had to tune some tests which
were checking expected plans, because of missing merge.
Pull request is here - https://github.com/apache/calcite/pull/931
> sql2rel fails on join between table function and other table
>
>
> Key: CALCITE-2667
> URL: https://issues.apache.org/jira/browse/CALCITE-2667
> Project: Calcite
> Issue Type: Bug
>Reporter: Piotr Bojko
>Assignee: Julian Hyde
>Priority: Major
>
> Bug reproduction is here -
> https://github.com/ptrbojko/calcite/tree/bug/CALCITE-2667
> {noformat}
> > java.lang.AssertionError: Field ordinal 2 is invalid for type
> > 'RecordType(VARCHAR TYPE, VARCHAR CODEVALUE)'
> > at
> > org.apache.calcite.rex.RexBuilder.makeFieldAccess(RexBuilder.java:188)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.convertIdentifier(SqlToRelConverter.java:3616)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.access$2100(SqlToRelConverter.java:215)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:4691)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:3987)
> > at org.apache.calcite.sql.SqlIdentifier.accept(SqlIdentifier.java:334)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:4551)
> > at
> > org.apache.calcite.sql2rel.StandardConvertletTable.lambda$new$9(StandardConvertletTable.java:204)
> > at
> > org.apache.calcite.sql2rel.SqlNodeToRexConverterImpl.convertCall(SqlNodeToRexConverterImpl.java:63)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:4682)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:3987)
> > at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:138)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:4551)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectList(SqlToRelConverter.java:3830)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:668)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:625)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3074)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:561)
> > at
[jira] [Commented] (CALCITE-2667) sql2rel fails on join between table function and other table
[
https://issues.apache.org/jira/browse/CALCITE-2667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16693119#comment-16693119
]
Piotr Bojko commented on CALCITE-2667:
--
[~julianhyde] ok
I have discovered that RelOptUtil.pushDownJoinConditions alters relnodes
registered in SqlToRelConverter as leaves. I've patched this.
But now I've discovered also that SqlToTelConverter.Blackboard.lookupExp is not
compatible with SqlToRelConverter.convertIdentifier. The first logic traverse
the leaves and return coordinates (like offset) in leaves in an appropriate
order. This information is then used in the second logic and the coordinates
are applied to SqlToTelConverter.Blackboard.inputs (through adjustInputRef(..)
-> bb.getRootField). This leades to inproper fields mappings.
Those are assumptions only, I wonder whether
SqlToTelConverter.Blackboard.lookupExp should be modified to return coordinates
in inputs (which tends to be higher in Rel tree than leaves) or bb.getRootField
should use leaves.
> sql2rel fails on join between table function and other table
>
>
> Key: CALCITE-2667
> URL: https://issues.apache.org/jira/browse/CALCITE-2667
> Project: Calcite
> Issue Type: Bug
>Reporter: Piotr Bojko
>Assignee: Julian Hyde
>Priority: Major
>
> Bug reproduction is here -
> https://github.com/ptrbojko/calcite/tree/bug/CALCITE-2667
> {noformat}
> > java.lang.AssertionError: Field ordinal 2 is invalid for type
> > 'RecordType(VARCHAR TYPE, VARCHAR CODEVALUE)'
> > at
> > org.apache.calcite.rex.RexBuilder.makeFieldAccess(RexBuilder.java:188)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.convertIdentifier(SqlToRelConverter.java:3616)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.access$2100(SqlToRelConverter.java:215)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:4691)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:3987)
> > at org.apache.calcite.sql.SqlIdentifier.accept(SqlIdentifier.java:334)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:4551)
> > at
> > org.apache.calcite.sql2rel.StandardConvertletTable.lambda$new$9(StandardConvertletTable.java:204)
> > at
> > org.apache.calcite.sql2rel.SqlNodeToRexConverterImpl.convertCall(SqlNodeToRexConverterImpl.java:63)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:4682)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:3987)
> > at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:138)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:4551)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectList(SqlToRelConverter.java:3830)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:668)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:625)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3074)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:561)
> > at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:265)
> > at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:231)
> > at
> > org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:772)
> > at
> > org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:636)
> > at
> > org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:606)
> > at
> > org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:229)
> > at
> > org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:550)
> > at
> > org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:675)
> > at
> > org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:156)
> > at
> > org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:227)
> > at net.hydromatic.quidem.Quidem.checkResult(Quidem.java:322)
> > at net.hydromatic.quidem.Quidem.access$2800(Quidem.java:54)
> > at
> > net.hydromatic.quidem.Quidem$ContextImpl.checkResult(Quidem.java:1747)
> > at
> > net.hydromatic.quidem.Quidem$CheckResultCommand.execute(Quidem.java:1078)
> > at
> > net.hydromatic.quidem.Quidem$CompositeCommand.execute(Quidem.java:1548)
> > at
[jira] [Closed] (CALCITE-2613) NPE when Avatica used as JDBC transport for Calcite and dynamic param ? used
[
https://issues.apache.org/jira/browse/CALCITE-2613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Piotr Bojko closed CALCITE-2613.
Resolution: Fixed
Fix Version/s: 1.18.0
[~elserj] [~julianhyde] I am closing this, because it was patched in CALCITE-563
> NPE when Avatica used as JDBC transport for Calcite and dynamic param ? used
> --
>
> Key: CALCITE-2613
> URL: https://issues.apache.org/jira/browse/CALCITE-2613
> Project: Calcite
> Issue Type: Bug
> Components: avatica, core
>Affects Versions: 1.17.0, avatica-1.12.0, 1.18.0
>Reporter: Piotr Bojko
>Priority: Major
> Fix For: 1.18.0
>
>
> This is a follow from dev@apache forum discussion. When avatica is wrapping
> through JdbcMeta a calcite connection and prepared statement contains dynamic
> parameters, then AvaticaParameters.toProto throws NPE (underlying Builder of
> Common.AvaticaParameter to be exact).
> FYI [~elserj]
> I will attach a test case to this issue in a sec.
> {quote}
> An AvaticaParameter with a null classname sounds wrong to me. We should
> know the type (per the schema) for some variable, regardless of whether
> or not it is nullable.
> If you can put together a unit test showing what you're seeing in
> Avatica, that would go an extremely long way. It may also just be
> something Calcite is doing which should be corrected (so, a unit test
> there would be a starting point, too).
> Feel free to ping me on Jira. Thanks Piotr!
> On 10/4/18 9:08 AM, ptr.bo...@gmail.com wrote:
> > I've logged a JIRA for the first bug, with a fix proposal -
> > https://issues.apache.org/jira/browse/CALCITE-2609.
> >
> > But the case with AvaticaParameter NPE still remains unclear for me - in
> > terms of design. Help needed :)
> >
> > On Wed, Oct 3, 2018 at 4:14 PM ptr.bo...@gmail.com
> > wrote:
> >
> >> As for the nulls in AvaticaParameter class - I believe this is how calcite
> >> works. For example for the following query *"select * from filters where
> >> name = ?"* - despite the definition of filters table - Calcite will
> >> create org.apache.calcite.avatica.AvaticaParameter with nullable className.
> >>
> >> My case with more details is following: based on calcite-avatica/sever
> >> I've created a mini jdbc server (servlet) exposing Calcite connection with
> >> my custom schemas. I would like to expose my domain as an SQL database so
> >> with Calcite as an engine and domain translation and Avatica as a JDBC
> >> implementor the resulting implementation is very elegant and works great.
> >>
> >> However the same query *"select * from filters where name = ?" *run
> >> through avatica jdbc implementation is resulting NPE
> >> in Common.AvaticaParameter AvaticaParameter.toProto().
> >>
> >> On Wed, Oct 3, 2018 at 12:46 AM Josh Elser wrote:
> >>
> >>> re: nulls on className, that's how Protobuf itself works. You can't set
> >>> null for an attribute.
> >>>
> >>> What is the circumstance where you would have a null className on an
> >>> AvaticaParameter?
> >>>
> >>> We could proactively check in the constructor to AvaticaParameter that
> >>> you don't provide null arguments, but that could be argued in either
> >>> direction (e.g. you should not provide null arguments in the first place).
> >>>
> >>> On 10/2/18 5:11 PM, ptr.bo...@gmail.com wrote:
> Hello,
>
> It seems that my case consists of two bugs:
>
> First one is similar to what I've already patched twice - Calcite pushes
> too much to underlying jdbc schema, in this case "?" operator. Resulting
> subquery onto jdbc schema ends with error about it (? not resolved).
> >>> This
> one belongs to Calcite.
>
> The second one is located
> at org.apache.calcite.avatica.AvaticaParameter.toProto method.
> AvaticaParameter can be a live nullable className but
> Common.AvaticaParameter does not allow to set nulls on className.
> >>> toProto
> method - please verify me - should be more carefull about it and not set
> className on a builder when it is null. This one belongs to Avatica.
>
> If anyone has time to check me it would be great. I will log then each
> >>> bug
> to appropriate apache project in Jira. I should patch first one fairly
> >>> easy.
>
> Regards,
> Piotr
>
> On Mon, Oct 1, 2018 at 1:50 PM Francis Chuang
> wrote:
>
> > Hey Piotr,
> >
> > Thanks for reporting this! I am not familiar with Avatica's internals,
> > so can't recommend how this can be fixed. However, I would suggest
> > writing a test case to reproduce the problem in the meantime.
> >
> > Francis
> >
> > On 1/10/2018 8:59 PM, ptr.bo...@gmail.com wrote:
> >> Hello fellow calcite dev team :)
> >>
>
[jira] [Closed] (CALCITE-2609) Dynamic parameters ? pushed to underlying jdbc schema
[ https://issues.apache.org/jira/browse/CALCITE-2609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Piotr Bojko closed CALCITE-2609. Resolution: Fixed [~julianhyde] I am closing this, because it was patched in CALCITE-563 > Dynamic parameters ? pushed to underlying jdbc schema > - > > Key: CALCITE-2609 > URL: https://issues.apache.org/jira/browse/CALCITE-2609 > Project: Calcite > Issue Type: Bug >Affects Versions: 1.17.0 >Reporter: Piotr Bojko >Assignee: Julian Hyde >Priority: Major > > When using PreparedStatement parameters "?" they can be pushed down to jdbc > subschemas which cause an error. > RexDynamicParam should now be pushed to jdbc schema. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2667) sql2rel fails on join between table function and other table
[
https://issues.apache.org/jira/browse/CALCITE-2667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16691689#comment-16691689
]
Piotr Bojko commented on CALCITE-2667:
--
[~julianhyde] do you have any hints on this?
> sql2rel fails on join between table function and other table
>
>
> Key: CALCITE-2667
> URL: https://issues.apache.org/jira/browse/CALCITE-2667
> Project: Calcite
> Issue Type: Bug
>Reporter: Piotr Bojko
>Assignee: Julian Hyde
>Priority: Major
>
> Bug reproduction is here -
> https://github.com/ptrbojko/calcite/tree/bug/CALCITE-2667
> {noformat}
> > java.lang.AssertionError: Field ordinal 2 is invalid for type
> > 'RecordType(VARCHAR TYPE, VARCHAR CODEVALUE)'
> > at
> > org.apache.calcite.rex.RexBuilder.makeFieldAccess(RexBuilder.java:188)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.convertIdentifier(SqlToRelConverter.java:3616)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.access$2100(SqlToRelConverter.java:215)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:4691)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:3987)
> > at org.apache.calcite.sql.SqlIdentifier.accept(SqlIdentifier.java:334)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:4551)
> > at
> > org.apache.calcite.sql2rel.StandardConvertletTable.lambda$new$9(StandardConvertletTable.java:204)
> > at
> > org.apache.calcite.sql2rel.SqlNodeToRexConverterImpl.convertCall(SqlNodeToRexConverterImpl.java:63)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:4682)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:3987)
> > at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:138)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:4551)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectList(SqlToRelConverter.java:3830)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:668)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:625)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3074)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:561)
> > at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:265)
> > at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:231)
> > at
> > org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:772)
> > at
> > org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:636)
> > at
> > org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:606)
> > at
> > org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:229)
> > at
> > org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:550)
> > at
> > org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:675)
> > at
> > org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:156)
> > at
> > org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:227)
> > at net.hydromatic.quidem.Quidem.checkResult(Quidem.java:322)
> > at net.hydromatic.quidem.Quidem.access$2800(Quidem.java:54)
> > at
> > net.hydromatic.quidem.Quidem$ContextImpl.checkResult(Quidem.java:1747)
> > at
> > net.hydromatic.quidem.Quidem$CheckResultCommand.execute(Quidem.java:1078)
> > at
> > net.hydromatic.quidem.Quidem$CompositeCommand.execute(Quidem.java:1548)
> > at net.hydromatic.quidem.Quidem.execute(Quidem.java:216)
> > at org.apache.calcite.test.QuidemTest.checkRun(QuidemTest.java:161)
> > at org.apache.calcite.test.QuidemTest.test(QuidemTest.java:209)
> > 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)
> >
[jira] [Comment Edited] (CALCITE-2667) sql2rel fails on join between table function and other table
[
https://issues.apache.org/jira/browse/CALCITE-2667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16691621#comment-16691621
]
Piotr Bojko edited comment on CALCITE-2667 at 11/19/18 12:10 PM:
-
When RelOptUtil.pushDownJoinConditions is called then new Join is created from
original and then - SqlToRelConverter.leaves becomes not sync with new join.
I've tried sync those relnodes in leaves (by swapping old with new one), but
then for some tests have:
{quote}java.lang.AssertionError
at
org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.getRootField(SqlToRelConverter.java:4357){quote}
was (Author: ptrbojko):
When RelOptUtil.pushDownJoinConditions is called then new Join is created from
original and then - SqlToRelConverter.leaves becomes not sync with new join.
I've tried swapping relnodes, but then for some tests have:
{quote}java.lang.AssertionError
at
org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.getRootField(SqlToRelConverter.java:4357){quote}
> sql2rel fails on join between table function and other table
>
>
> Key: CALCITE-2667
> URL: https://issues.apache.org/jira/browse/CALCITE-2667
> Project: Calcite
> Issue Type: Bug
>Reporter: Piotr Bojko
>Assignee: Julian Hyde
>Priority: Major
>
> Bug reproduction is here -
> https://github.com/ptrbojko/calcite/tree/bug/CALCITE-2667
> {noformat}
> > java.lang.AssertionError: Field ordinal 2 is invalid for type
> > 'RecordType(VARCHAR TYPE, VARCHAR CODEVALUE)'
> > at
> > org.apache.calcite.rex.RexBuilder.makeFieldAccess(RexBuilder.java:188)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.convertIdentifier(SqlToRelConverter.java:3616)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.access$2100(SqlToRelConverter.java:215)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:4691)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:3987)
> > at org.apache.calcite.sql.SqlIdentifier.accept(SqlIdentifier.java:334)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:4551)
> > at
> > org.apache.calcite.sql2rel.StandardConvertletTable.lambda$new$9(StandardConvertletTable.java:204)
> > at
> > org.apache.calcite.sql2rel.SqlNodeToRexConverterImpl.convertCall(SqlNodeToRexConverterImpl.java:63)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:4682)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:3987)
> > at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:138)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:4551)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectList(SqlToRelConverter.java:3830)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:668)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:625)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3074)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:561)
> > at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:265)
> > at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:231)
> > at
> > org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:772)
> > at
> > org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:636)
> > at
> > org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:606)
> > at
> > org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:229)
> > at
> > org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:550)
> > at
> > org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:675)
> > at
> > org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:156)
> > at
> > org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:227)
> > at net.hydromatic.quidem.Quidem.checkResult(Quidem.java:322)
> > at net.hydromatic.quidem.Quidem.access$2800(Quidem.java:54)
> > at
> > net.hydromatic.quidem.Quidem$ContextImpl.checkResult(Quidem.java:1747)
> > at
> > net.hydromatic.quidem.Quidem$CheckResultCommand.execute(Quidem.java:1078)
> > at
> > net.hydromatic.quidem.Quidem$CompositeCommand.execute(Quidem.java:1548)
> > at
[jira] [Commented] (CALCITE-2667) sql2rel fails on join between table function and other table
[
https://issues.apache.org/jira/browse/CALCITE-2667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16691621#comment-16691621
]
Piotr Bojko commented on CALCITE-2667:
--
When RelOptUtil.pushDownJoinConditions is called then new Join is created from
original and then - SqlToRelConverter.leaves becomes not sync with new join.
I've tried swapping relnodes, but then for some tests have:
{quote}java.lang.AssertionError
at
org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.getRootField(SqlToRelConverter.java:4357){quote}
> sql2rel fails on join between table function and other table
>
>
> Key: CALCITE-2667
> URL: https://issues.apache.org/jira/browse/CALCITE-2667
> Project: Calcite
> Issue Type: Bug
>Reporter: Piotr Bojko
>Assignee: Julian Hyde
>Priority: Major
>
> Bug reproduction is here -
> https://github.com/ptrbojko/calcite/tree/bug/CALCITE-2667
> {noformat}
> > java.lang.AssertionError: Field ordinal 2 is invalid for type
> > 'RecordType(VARCHAR TYPE, VARCHAR CODEVALUE)'
> > at
> > org.apache.calcite.rex.RexBuilder.makeFieldAccess(RexBuilder.java:188)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.convertIdentifier(SqlToRelConverter.java:3616)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.access$2100(SqlToRelConverter.java:215)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:4691)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:3987)
> > at org.apache.calcite.sql.SqlIdentifier.accept(SqlIdentifier.java:334)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:4551)
> > at
> > org.apache.calcite.sql2rel.StandardConvertletTable.lambda$new$9(StandardConvertletTable.java:204)
> > at
> > org.apache.calcite.sql2rel.SqlNodeToRexConverterImpl.convertCall(SqlNodeToRexConverterImpl.java:63)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:4682)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:3987)
> > at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:138)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:4551)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectList(SqlToRelConverter.java:3830)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:668)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:625)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3074)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:561)
> > at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:265)
> > at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:231)
> > at
> > org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:772)
> > at
> > org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:636)
> > at
> > org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:606)
> > at
> > org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:229)
> > at
> > org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:550)
> > at
> > org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:675)
> > at
> > org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:156)
> > at
> > org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:227)
> > at net.hydromatic.quidem.Quidem.checkResult(Quidem.java:322)
> > at net.hydromatic.quidem.Quidem.access$2800(Quidem.java:54)
> > at
> > net.hydromatic.quidem.Quidem$ContextImpl.checkResult(Quidem.java:1747)
> > at
> > net.hydromatic.quidem.Quidem$CheckResultCommand.execute(Quidem.java:1078)
> > at
> > net.hydromatic.quidem.Quidem$CompositeCommand.execute(Quidem.java:1548)
> > at net.hydromatic.quidem.Quidem.execute(Quidem.java:216)
> > at org.apache.calcite.test.QuidemTest.checkRun(QuidemTest.java:161)
> > at org.apache.calcite.test.QuidemTest.test(QuidemTest.java:209)
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > at
> > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> > at
> > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > at
[jira] [Commented] (CALCITE-563) JDBC adapter fails to execute a prepared statement with a bind variable
[
https://issues.apache.org/jira/browse/CALCITE-563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16687724#comment-16687724
]
Piotr Bojko commented on CALCITE-563:
-
Hey [~julianhyde] kindly reminder about this :)
> JDBC adapter fails to execute a prepared statement with a bind variable
> ---
>
> Key: CALCITE-563
> URL: https://issues.apache.org/jira/browse/CALCITE-563
> Project: Calcite
> Issue Type: Bug
> Components: jdbc-adapter
>Affects Versions: 1.0.0-incubating
> Environment: Any
>Reporter: Ng Jiunn Jye
>Assignee: Julian Hyde
>Priority: Major
> Labels: newbie
>
> Description:
> Calcite fail to execute PreparedStatement bind variable to external JDBC
> datasource.
> Problem:
> RexCall of kind DYNAMIC_PARAM is not supported in JdbcAdaptor.
> Error StackTrace:
> {noformat}
> java.sql.SQLException: Error while preparing statement [SELECT ID, VALS FROM
> T1 where id = ?]
> at org.apache.calcite.avatica.Helper.createException(Helper.java:39)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.prepareStatement(CalciteConnectionImpl.java:161)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.prepareStatement(CalciteConnectionImpl.java:1)
> at
> org.apache.calcite.avatica.AvaticaConnection.prepareStatement(AvaticaConnection.java:121)
> at
> org.apache.calcite.jdbc.TestPrepareStatementBindVar.main(TestPrepareStatementBindVar.java:48)
> Caused by: java.lang.ClassCastException:
> org.apache.calcite.rex.RexDynamicParam incompatible with
> org.apache.calcite.rex.RexCall
> at
> org.apache.calcite.adapter.jdbc.JdbcImplementor$Context.toSql(JdbcImplementor.java:210)
> at
> org.apache.calcite.adapter.jdbc.JdbcImplementor$Context.toSql(JdbcImplementor.java:268)
> at
> org.apache.calcite.adapter.jdbc.JdbcImplementor$Context.toSql(JdbcImplementor.java:212)
> at
> org.apache.calcite.adapter.jdbc.JdbcRules$JdbcFilter.implement(JdbcRules.java:538)
> at
> org.apache.calcite.adapter.jdbc.JdbcImplementor.visitChild(JdbcImplementor.java:118)
> at
> org.apache.calcite.adapter.jdbc.JdbcToEnumerableConverter.generateSql(JdbcToEnumerableConverter.java:286)
> at
> org.apache.calcite.adapter.jdbc.JdbcToEnumerableConverter.implement(JdbcToEnumerableConverter.java:89)
> at
> org.apache.calcite.adapter.enumerable.EnumerableRelImplementor.implementRoot(EnumerableRelImplementor.java:99)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl$CalcitePreparingStmt.implement(CalcitePrepareImpl.java:867)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:298)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:192)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:486)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:383)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:352)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:174)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.prepareStatement(CalciteConnectionImpl.java:157)
> {noformat}
> Test Code:
> {code:java}
> package org.apache.calcite.jdbc;
> import java.sql.Connection;
> import java.sql.DriverManager;
> import java.sql.PreparedStatement;
> import java.sql.ResultSet;
> import java.sql.Statement;
> import java.util.Properties;
> import org.hsqldb.jdbcDriver;
> public class TestPrepareStatementBindVar {
> public static void main(String[] args) {
> try {
> String hsqldbMemUrl = "jdbc:hsqldb:mem:.";
> Connection baseConnection =
> DriverManager.getConnection(hsqldbMemUrl);
> Statement baseStmt =
> baseConnection.createStatement();
> baseStmt.execute("CREATE TABLE T1 (\n"
> + "ID INTEGER,\n"
> + "VALS INTEGER)");
> baseStmt.execute("INSERT INTO T1 VALUES (1, 1)");
> baseStmt.close();
> baseConnection.commit();
> Properties info = new Properties();
> info.put("model",
> "inline:"
> + "{\n"
> + " version: '1.0',\n"
> + " defaultSchema: 'BASEJDBC',\n"
> + " schemas: [\n"
> + " {\n"
> + " type: 'jdbc',\n"
> + "
[jira] [Commented] (CALCITE-2667) sql2rel fails on join between table function and other table
[
https://issues.apache.org/jira/browse/CALCITE-2667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16687673#comment-16687673
]
Piotr Bojko commented on CALCITE-2667:
--
Hello, any thoughts how this can be fixed? I would fix myself with some hints
what is wrong and where.
> sql2rel fails on join between table function and other table
>
>
> Key: CALCITE-2667
> URL: https://issues.apache.org/jira/browse/CALCITE-2667
> Project: Calcite
> Issue Type: Bug
>Reporter: Piotr Bojko
>Assignee: Julian Hyde
>Priority: Major
>
> Bug reproduction is here -
> https://github.com/ptrbojko/calcite/tree/bug/CALCITE-2667
> {noformat}
> > java.lang.AssertionError: Field ordinal 2 is invalid for type
> > 'RecordType(VARCHAR TYPE, VARCHAR CODEVALUE)'
> > at
> > org.apache.calcite.rex.RexBuilder.makeFieldAccess(RexBuilder.java:188)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.convertIdentifier(SqlToRelConverter.java:3616)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.access$2100(SqlToRelConverter.java:215)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:4691)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:3987)
> > at org.apache.calcite.sql.SqlIdentifier.accept(SqlIdentifier.java:334)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:4551)
> > at
> > org.apache.calcite.sql2rel.StandardConvertletTable.lambda$new$9(StandardConvertletTable.java:204)
> > at
> > org.apache.calcite.sql2rel.SqlNodeToRexConverterImpl.convertCall(SqlNodeToRexConverterImpl.java:63)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:4682)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:3987)
> > at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:138)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:4551)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectList(SqlToRelConverter.java:3830)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:668)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:625)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3074)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:561)
> > at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:265)
> > at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:231)
> > at
> > org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:772)
> > at
> > org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:636)
> > at
> > org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:606)
> > at
> > org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:229)
> > at
> > org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:550)
> > at
> > org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:675)
> > at
> > org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:156)
> > at
> > org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:227)
> > at net.hydromatic.quidem.Quidem.checkResult(Quidem.java:322)
> > at net.hydromatic.quidem.Quidem.access$2800(Quidem.java:54)
> > at
> > net.hydromatic.quidem.Quidem$ContextImpl.checkResult(Quidem.java:1747)
> > at
> > net.hydromatic.quidem.Quidem$CheckResultCommand.execute(Quidem.java:1078)
> > at
> > net.hydromatic.quidem.Quidem$CompositeCommand.execute(Quidem.java:1548)
> > at net.hydromatic.quidem.Quidem.execute(Quidem.java:216)
> > at org.apache.calcite.test.QuidemTest.checkRun(QuidemTest.java:161)
> > at org.apache.calcite.test.QuidemTest.test(QuidemTest.java:209)
> > 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
> >
[jira] [Commented] (CALCITE-2667) sql2rel fails on join between table function and other table
[
https://issues.apache.org/jira/browse/CALCITE-2667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686359#comment-16686359
]
Piotr Bojko commented on CALCITE-2667:
--
It seems that SqlToRelConverter.leaves does not contain one of the
LogicalProject or it contains the old instance (before mutation?) and thus
flattening fails. But I am not familiar with this area of Calcite.
> sql2rel fails on join between table function and other table
>
>
> Key: CALCITE-2667
> URL: https://issues.apache.org/jira/browse/CALCITE-2667
> Project: Calcite
> Issue Type: Bug
>Reporter: Piotr Bojko
>Assignee: Julian Hyde
>Priority: Major
>
> Bug reproduction is here -
> https://github.com/ptrbojko/calcite/tree/bug/CALCITE-2667
> {noformat}
> > java.lang.AssertionError: Field ordinal 2 is invalid for type
> > 'RecordType(VARCHAR TYPE, VARCHAR CODEVALUE)'
> > at
> > org.apache.calcite.rex.RexBuilder.makeFieldAccess(RexBuilder.java:188)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.convertIdentifier(SqlToRelConverter.java:3616)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.access$2100(SqlToRelConverter.java:215)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:4691)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:3987)
> > at org.apache.calcite.sql.SqlIdentifier.accept(SqlIdentifier.java:334)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:4551)
> > at
> > org.apache.calcite.sql2rel.StandardConvertletTable.lambda$new$9(StandardConvertletTable.java:204)
> > at
> > org.apache.calcite.sql2rel.SqlNodeToRexConverterImpl.convertCall(SqlNodeToRexConverterImpl.java:63)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:4682)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:3987)
> > at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:138)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:4551)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectList(SqlToRelConverter.java:3830)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:668)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:625)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3074)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:561)
> > at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:265)
> > at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:231)
> > at
> > org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:772)
> > at
> > org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:636)
> > at
> > org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:606)
> > at
> > org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:229)
> > at
> > org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:550)
> > at
> > org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:675)
> > at
> > org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:156)
> > at
> > org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:227)
> > at net.hydromatic.quidem.Quidem.checkResult(Quidem.java:322)
> > at net.hydromatic.quidem.Quidem.access$2800(Quidem.java:54)
> > at
> > net.hydromatic.quidem.Quidem$ContextImpl.checkResult(Quidem.java:1747)
> > at
> > net.hydromatic.quidem.Quidem$CheckResultCommand.execute(Quidem.java:1078)
> > at
> > net.hydromatic.quidem.Quidem$CompositeCommand.execute(Quidem.java:1548)
> > at net.hydromatic.quidem.Quidem.execute(Quidem.java:216)
> > at org.apache.calcite.test.QuidemTest.checkRun(QuidemTest.java:161)
> > at org.apache.calcite.test.QuidemTest.test(QuidemTest.java:209)
> > 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
> >
[jira] [Commented] (CALCITE-2667) sql2rel fails on join between table function and other table
[
https://issues.apache.org/jira/browse/CALCITE-2667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686210#comment-16686210
]
Piotr Bojko commented on CALCITE-2667:
--
I have pushed the last commit now, sorry for that.
> sql2rel fails on join between table function and other table
>
>
> Key: CALCITE-2667
> URL: https://issues.apache.org/jira/browse/CALCITE-2667
> Project: Calcite
> Issue Type: Bug
>Reporter: Piotr Bojko
>Assignee: Julian Hyde
>Priority: Major
>
> Bug reproduction is here -
> https://github.com/ptrbojko/calcite/tree/bug/CALCITE-2667
> {noformat}
> > java.lang.AssertionError: Field ordinal 2 is invalid for type
> > 'RecordType(VARCHAR TYPE, VARCHAR CODEVALUE)'
> > at
> > org.apache.calcite.rex.RexBuilder.makeFieldAccess(RexBuilder.java:188)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.convertIdentifier(SqlToRelConverter.java:3616)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.access$2100(SqlToRelConverter.java:215)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:4691)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:3987)
> > at org.apache.calcite.sql.SqlIdentifier.accept(SqlIdentifier.java:334)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:4551)
> > at
> > org.apache.calcite.sql2rel.StandardConvertletTable.lambda$new$9(StandardConvertletTable.java:204)
> > at
> > org.apache.calcite.sql2rel.SqlNodeToRexConverterImpl.convertCall(SqlNodeToRexConverterImpl.java:63)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:4682)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:3987)
> > at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:138)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:4551)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectList(SqlToRelConverter.java:3830)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:668)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:625)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3074)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:561)
> > at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:265)
> > at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:231)
> > at
> > org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:772)
> > at
> > org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:636)
> > at
> > org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:606)
> > at
> > org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:229)
> > at
> > org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:550)
> > at
> > org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:675)
> > at
> > org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:156)
> > at
> > org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:227)
> > at net.hydromatic.quidem.Quidem.checkResult(Quidem.java:322)
> > at net.hydromatic.quidem.Quidem.access$2800(Quidem.java:54)
> > at
> > net.hydromatic.quidem.Quidem$ContextImpl.checkResult(Quidem.java:1747)
> > at
> > net.hydromatic.quidem.Quidem$CheckResultCommand.execute(Quidem.java:1078)
> > at
> > net.hydromatic.quidem.Quidem$CompositeCommand.execute(Quidem.java:1548)
> > at net.hydromatic.quidem.Quidem.execute(Quidem.java:216)
> > at org.apache.calcite.test.QuidemTest.checkRun(QuidemTest.java:161)
> > at org.apache.calcite.test.QuidemTest.test(QuidemTest.java:209)
> > 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)
[jira] [Commented] (CALCITE-2667) sql2rel fails on join between table function and other table
[
https://issues.apache.org/jira/browse/CALCITE-2667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16685875#comment-16685875
]
Piotr Bojko commented on CALCITE-2667:
--
I've added another test case, see
TableFunctionTest.testTableFunctionJoinWithJdbcTable.
I am willing to help, any hints appreciated.
> sql2rel fails on join between table function and other table
>
>
> Key: CALCITE-2667
> URL: https://issues.apache.org/jira/browse/CALCITE-2667
> Project: Calcite
> Issue Type: Bug
>Reporter: Piotr Bojko
>Assignee: Julian Hyde
>Priority: Major
>
> Bug reproduction is here -
> https://github.com/ptrbojko/calcite/tree/bug/CALCITE-2667
> {noformat}
> > java.lang.AssertionError: Field ordinal 2 is invalid for type
> > 'RecordType(VARCHAR TYPE, VARCHAR CODEVALUE)'
> > at
> > org.apache.calcite.rex.RexBuilder.makeFieldAccess(RexBuilder.java:188)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.convertIdentifier(SqlToRelConverter.java:3616)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.access$2100(SqlToRelConverter.java:215)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:4691)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:3987)
> > at org.apache.calcite.sql.SqlIdentifier.accept(SqlIdentifier.java:334)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:4551)
> > at
> > org.apache.calcite.sql2rel.StandardConvertletTable.lambda$new$9(StandardConvertletTable.java:204)
> > at
> > org.apache.calcite.sql2rel.SqlNodeToRexConverterImpl.convertCall(SqlNodeToRexConverterImpl.java:63)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:4682)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:3987)
> > at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:138)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:4551)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectList(SqlToRelConverter.java:3830)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:668)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:625)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3074)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:561)
> > at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:265)
> > at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:231)
> > at
> > org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:772)
> > at
> > org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:636)
> > at
> > org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:606)
> > at
> > org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:229)
> > at
> > org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:550)
> > at
> > org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:675)
> > at
> > org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:156)
> > at
> > org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:227)
> > at net.hydromatic.quidem.Quidem.checkResult(Quidem.java:322)
> > at net.hydromatic.quidem.Quidem.access$2800(Quidem.java:54)
> > at
> > net.hydromatic.quidem.Quidem$ContextImpl.checkResult(Quidem.java:1747)
> > at
> > net.hydromatic.quidem.Quidem$CheckResultCommand.execute(Quidem.java:1078)
> > at
> > net.hydromatic.quidem.Quidem$CompositeCommand.execute(Quidem.java:1548)
> > at net.hydromatic.quidem.Quidem.execute(Quidem.java:216)
> > at org.apache.calcite.test.QuidemTest.checkRun(QuidemTest.java:161)
> > at org.apache.calcite.test.QuidemTest.test(QuidemTest.java:209)
> > 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
>
[jira] [Commented] (CALCITE-2667) sql2rel fails on join between table function and other table
[
https://issues.apache.org/jira/browse/CALCITE-2667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16685341#comment-16685341
]
Piotr Bojko commented on CALCITE-2667:
--
It seems that o previous calcite 1.18 snapshots this bug had following result:
{noformat}
[INFO] [talledLocalContainer] java.lang.IndexOutOfBoundsException: Index: 1,
Size: 1
[INFO] [talledLocalContainer] at
java.util.ArrayList.rangeCheck(ArrayList.java:657)
[INFO] [talledLocalContainer] at java.util.ArrayList.get(ArrayList.java:433)
[INFO] [talledLocalContainer] at
org.apache.calcite.sql2rel.SqlToRelConverter$LookupContext.findRel(SqlToRelConverter.java:5155)
[INFO] [talledLocalContainer] at
org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.lookup(SqlToRelConverter.java:4326)
[INFO] [talledLocalContainer] at
org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.lookupExp(SqlToRelConverter.java:4271)
[INFO] [talledLocalContainer] at
org.apache.calcite.sql2rel.SqlToRelConverter.convertIdentifier(SqlToRelConverter.java:3618)
[INFO] [talledLocalContainer] at
org.apache.calcite.sql2rel.SqlToRelConverter.access$2100(SqlToRelConverter.java:212)
[INFO] [talledLocalContainer] at
org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:4696)
[INFO] [talledLocalContainer] at
org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:3994)
[INFO] [talledLocalContainer] at
org.apache.calcite.sql.SqlIdentifier.accept(SqlIdentifier.java:334)
[INFO] [talledLocalContainer] at
org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:4558)
[INFO] [talledLocalContainer] at
org.apache.calcite.sql2rel.SqlToRelConverter$AggConverter.addGroupExpr(SqlToRelConverter.java:4861)
[INFO] [talledLocalContainer] at
org.apache.calcite.sql2rel.SqlToRelConverter.createAggImpl(SqlToRelConverter.java:2748)
[INFO] [talledLocalContainer] at
org.apache.calcite.sql2rel.SqlToRelConverter.convertAgg(SqlToRelConverter.java:2698)
[INFO] [talledLocalContainer] at
org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:660)
[INFO] [talledLocalContainer] at
org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:622)
[INFO] [talledLocalContainer] at
org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3068)
[INFO] [talledLocalContainer] at
org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:558)
[INFO] [talledLocalContainer] at
org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:264)
[INFO] [talledLocalContainer] at
org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:230)
[INFO] [talledLocalContainer] at
org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:774)
[INFO] [talledLocalContainer] at
org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:638)
[INFO] [talledLocalContainer] at
org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:608)
[INFO] [talledLocalContainer] at
org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:238)
[INFO] [talledLocalContainer] at
org.apache.calcite.jdbc.CalciteConnectionImpl.prepareStatement_(CalciteConnectionImpl.java:220)
[INFO] [talledLocalContainer] at
org.apache.calcite.jdbc.CalciteConnectionImpl.prepareStatement(CalciteConnectionImpl.java:209)
[INFO] [talledLocalContainer] at
org.apache.calcite.jdbc.CalciteConnectionImpl.prepareStatement(CalciteConnectionImpl.java:96)
[INFO] [talledLocalContainer] at
org.apache.calcite.avatica.AvaticaConnection.prepareStatement(AvaticaConnection.java:175)
{noformat}
> sql2rel fails on join between table function and other table
>
>
> Key: CALCITE-2667
> URL: https://issues.apache.org/jira/browse/CALCITE-2667
> Project: Calcite
> Issue Type: Bug
>Reporter: Piotr Bojko
>Assignee: Julian Hyde
>Priority: Major
>
> Bug reproduction is here -
> https://github.com/ptrbojko/calcite/tree/bug/CALCITE-2667
> {noformat}
> > java.lang.AssertionError: Field ordinal 2 is invalid for type
> > 'RecordType(VARCHAR TYPE, VARCHAR CODEVALUE)'
> > at
> > org.apache.calcite.rex.RexBuilder.makeFieldAccess(RexBuilder.java:188)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.convertIdentifier(SqlToRelConverter.java:3616)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.access$2100(SqlToRelConverter.java:215)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:4691)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:3987)
> > at
[jira] [Updated] (CALCITE-2667) sql2rel fails on join between table function and other table
[
https://issues.apache.org/jira/browse/CALCITE-2667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Piotr Bojko updated CALCITE-2667:
-
Description:
Bug reproduction is here -
https://github.com/ptrbojko/calcite/tree/bug/CALCITE-2667
{noformat}
> java.lang.AssertionError: Field ordinal 2 is invalid for type
> 'RecordType(VARCHAR TYPE, VARCHAR CODEVALUE)'
> at
> org.apache.calcite.rex.RexBuilder.makeFieldAccess(RexBuilder.java:188)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertIdentifier(SqlToRelConverter.java:3616)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.access$2100(SqlToRelConverter.java:215)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:4691)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:3987)
> at org.apache.calcite.sql.SqlIdentifier.accept(SqlIdentifier.java:334)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:4551)
> at
> org.apache.calcite.sql2rel.StandardConvertletTable.lambda$new$9(StandardConvertletTable.java:204)
> at
> org.apache.calcite.sql2rel.SqlNodeToRexConverterImpl.convertCall(SqlNodeToRexConverterImpl.java:63)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:4682)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:3987)
> at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:138)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:4551)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectList(SqlToRelConverter.java:3830)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:668)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:625)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3074)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:561)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:265)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:231)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:772)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:636)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:606)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:229)
> at
> org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:550)
> at
> org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:675)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:156)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:227)
> at net.hydromatic.quidem.Quidem.checkResult(Quidem.java:322)
> at net.hydromatic.quidem.Quidem.access$2800(Quidem.java:54)
> at
> net.hydromatic.quidem.Quidem$ContextImpl.checkResult(Quidem.java:1747)
> at
> net.hydromatic.quidem.Quidem$CheckResultCommand.execute(Quidem.java:1078)
> at
> net.hydromatic.quidem.Quidem$CompositeCommand.execute(Quidem.java:1548)
> at net.hydromatic.quidem.Quidem.execute(Quidem.java:216)
> at org.apache.calcite.test.QuidemTest.checkRun(QuidemTest.java:161)
> at org.apache.calcite.test.QuidemTest.test(QuidemTest.java:209)
> 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.apache.maven.surefire.junitcore.pc.Scheduler$1.run(Scheduler.java:410)
> at
>
[jira] [Updated] (CALCITE-2667) sql2rel fails on join between table function and other table
[
https://issues.apache.org/jira/browse/CALCITE-2667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Piotr Bojko updated CALCITE-2667:
-
Description:
Bug reproduction is here -
https://github.com/ptrbojko/calcite/tree/bug/CALCITE-2667
{noformat}
> java.lang.AssertionError: Field ordinal 2 is invalid for type
> 'RecordType(VARCHAR TYPE, VARCHAR CODEVALUE)'
> at
> org.apache.calcite.rex.RexBuilder.makeFieldAccess(RexBuilder.java:188)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertIdentifier(SqlToRelConverter.java:3616)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.access$2100(SqlToRelConverter.java:215)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:4691)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:3987)
> at org.apache.calcite.sql.SqlIdentifier.accept(SqlIdentifier.java:334)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:4551)
> at
> org.apache.calcite.sql2rel.StandardConvertletTable.lambda$new$9(StandardConvertletTable.java:204)
> at
> org.apache.calcite.sql2rel.SqlNodeToRexConverterImpl.convertCall(SqlNodeToRexConverterImpl.java:63)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:4682)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:3987)
> at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:138)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:4551)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectList(SqlToRelConverter.java:3830)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:668)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:625)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3074)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:561)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:265)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:231)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:772)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:636)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:606)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:229)
> at
> org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:550)
> at
> org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:675)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:156)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:227)
> at net.hydromatic.quidem.Quidem.checkResult(Quidem.java:322)
> at net.hydromatic.quidem.Quidem.access$2800(Quidem.java:54)
> at
> net.hydromatic.quidem.Quidem$ContextImpl.checkResult(Quidem.java:1747)
> at
> net.hydromatic.quidem.Quidem$CheckResultCommand.execute(Quidem.java:1078)
> at
> net.hydromatic.quidem.Quidem$CompositeCommand.execute(Quidem.java:1548)
> at net.hydromatic.quidem.Quidem.execute(Quidem.java:216)
> at org.apache.calcite.test.QuidemTest.checkRun(QuidemTest.java:161)
> at org.apache.calcite.test.QuidemTest.test(QuidemTest.java:209)
> 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.apache.maven.surefire.junitcore.pc.Scheduler$1.run(Scheduler.java:410)
> at
>
[jira] [Created] (CALCITE-2667) sql2rel fails on join between table function and other table
Piotr Bojko created CALCITE-2667:
Summary: sql2rel fails on join between table function and other
table
Key: CALCITE-2667
URL: https://issues.apache.org/jira/browse/CALCITE-2667
Project: Calcite
Issue Type: Bug
Reporter: Piotr Bojko
Assignee: Julian Hyde
{noformat}
> java.lang.AssertionError: Field ordinal 2 is invalid for type
> 'RecordType(VARCHAR TYPE, VARCHAR CODEVALUE)'
> at
> org.apache.calcite.rex.RexBuilder.makeFieldAccess(RexBuilder.java:188)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertIdentifier(SqlToRelConverter.java:3616)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.access$2100(SqlToRelConverter.java:215)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:4691)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:3987)
> at org.apache.calcite.sql.SqlIdentifier.accept(SqlIdentifier.java:334)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:4551)
> at
> org.apache.calcite.sql2rel.StandardConvertletTable.lambda$new$9(StandardConvertletTable.java:204)
> at
> org.apache.calcite.sql2rel.SqlNodeToRexConverterImpl.convertCall(SqlNodeToRexConverterImpl.java:63)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:4682)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:3987)
> at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:138)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:4551)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectList(SqlToRelConverter.java:3830)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:668)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:625)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3074)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:561)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:265)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:231)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:772)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:636)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:606)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:229)
> at
> org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:550)
> at
> org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:675)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:156)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:227)
> at net.hydromatic.quidem.Quidem.checkResult(Quidem.java:322)
> at net.hydromatic.quidem.Quidem.access$2800(Quidem.java:54)
> at
> net.hydromatic.quidem.Quidem$ContextImpl.checkResult(Quidem.java:1747)
> at
> net.hydromatic.quidem.Quidem$CheckResultCommand.execute(Quidem.java:1078)
> at
> net.hydromatic.quidem.Quidem$CompositeCommand.execute(Quidem.java:1548)
> at net.hydromatic.quidem.Quidem.execute(Quidem.java:216)
> at org.apache.calcite.test.QuidemTest.checkRun(QuidemTest.java:161)
> at org.apache.calcite.test.QuidemTest.test(QuidemTest.java:209)
> 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
>
[jira] [Commented] (CALCITE-563) JDBC adapter fails to execute a prepared statement with a bind variable
[
https://issues.apache.org/jira/browse/CALCITE-563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16684430#comment-16684430
]
Piotr Bojko commented on CALCITE-563:
-
Hey, any thoughts on the pull?
> JDBC adapter fails to execute a prepared statement with a bind variable
> ---
>
> Key: CALCITE-563
> URL: https://issues.apache.org/jira/browse/CALCITE-563
> Project: Calcite
> Issue Type: Bug
> Components: jdbc-adapter
>Affects Versions: 1.0.0-incubating
> Environment: Any
>Reporter: Ng Jiunn Jye
>Assignee: Julian Hyde
>Priority: Major
> Labels: newbie
>
> Description:
> Calcite fail to execute PreparedStatement bind variable to external JDBC
> datasource.
> Problem:
> RexCall of kind DYNAMIC_PARAM is not supported in JdbcAdaptor.
> Error StackTrace:
> {noformat}
> java.sql.SQLException: Error while preparing statement [SELECT ID, VALS FROM
> T1 where id = ?]
> at org.apache.calcite.avatica.Helper.createException(Helper.java:39)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.prepareStatement(CalciteConnectionImpl.java:161)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.prepareStatement(CalciteConnectionImpl.java:1)
> at
> org.apache.calcite.avatica.AvaticaConnection.prepareStatement(AvaticaConnection.java:121)
> at
> org.apache.calcite.jdbc.TestPrepareStatementBindVar.main(TestPrepareStatementBindVar.java:48)
> Caused by: java.lang.ClassCastException:
> org.apache.calcite.rex.RexDynamicParam incompatible with
> org.apache.calcite.rex.RexCall
> at
> org.apache.calcite.adapter.jdbc.JdbcImplementor$Context.toSql(JdbcImplementor.java:210)
> at
> org.apache.calcite.adapter.jdbc.JdbcImplementor$Context.toSql(JdbcImplementor.java:268)
> at
> org.apache.calcite.adapter.jdbc.JdbcImplementor$Context.toSql(JdbcImplementor.java:212)
> at
> org.apache.calcite.adapter.jdbc.JdbcRules$JdbcFilter.implement(JdbcRules.java:538)
> at
> org.apache.calcite.adapter.jdbc.JdbcImplementor.visitChild(JdbcImplementor.java:118)
> at
> org.apache.calcite.adapter.jdbc.JdbcToEnumerableConverter.generateSql(JdbcToEnumerableConverter.java:286)
> at
> org.apache.calcite.adapter.jdbc.JdbcToEnumerableConverter.implement(JdbcToEnumerableConverter.java:89)
> at
> org.apache.calcite.adapter.enumerable.EnumerableRelImplementor.implementRoot(EnumerableRelImplementor.java:99)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl$CalcitePreparingStmt.implement(CalcitePrepareImpl.java:867)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:298)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:192)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:486)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:383)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:352)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:174)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.prepareStatement(CalciteConnectionImpl.java:157)
> {noformat}
> Test Code:
> {code:java}
> package org.apache.calcite.jdbc;
> import java.sql.Connection;
> import java.sql.DriverManager;
> import java.sql.PreparedStatement;
> import java.sql.ResultSet;
> import java.sql.Statement;
> import java.util.Properties;
> import org.hsqldb.jdbcDriver;
> public class TestPrepareStatementBindVar {
> public static void main(String[] args) {
> try {
> String hsqldbMemUrl = "jdbc:hsqldb:mem:.";
> Connection baseConnection =
> DriverManager.getConnection(hsqldbMemUrl);
> Statement baseStmt =
> baseConnection.createStatement();
> baseStmt.execute("CREATE TABLE T1 (\n"
> + "ID INTEGER,\n"
> + "VALS INTEGER)");
> baseStmt.execute("INSERT INTO T1 VALUES (1, 1)");
> baseStmt.close();
> baseConnection.commit();
> Properties info = new Properties();
> info.put("model",
> "inline:"
> + "{\n"
> + " version: '1.0',\n"
> + " defaultSchema: 'BASEJDBC',\n"
> + " schemas: [\n"
> + " {\n"
> + " type: 'jdbc',\n"
> + " name:
[jira] [Commented] (CALCITE-2663) CREATE FUNCTION SQL statement
[
https://issues.apache.org/jira/browse/CALCITE-2663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16683494#comment-16683494
]
Piotr Bojko commented on CALCITE-2663:
--
I wonder whether "AS class_name" is a valid use an "as" operator? In file URI
there is a mechanisms to point the class name already.
> CREATE FUNCTION SQL statement
> -
>
> Key: CALCITE-2663
> URL: https://issues.apache.org/jira/browse/CALCITE-2663
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.16.0, 1.17.0
>Reporter: ambition
>Assignee: Julian Hyde
>Priority: Minor
> Fix For: 1.16.0, 1.17.0
>
>
> support create function statement like hive:
>
>
> {code:java}
> CREATE FUNCTION [db_name.]function_name AS class_name
> [USING JAR|FILE|ARCHIVE 'file_uri' [, JAR|FILE|ARCHIVE 'file_uri'] ];
> {code}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-563) JDBC adapter fails to execute a prepared statement with a bind variable
[
https://issues.apache.org/jira/browse/CALCITE-563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16679629#comment-16679629
]
Piotr Bojko commented on CALCITE-563:
-
Here is a pull requested - https://github.com/apache/calcite/pull/907
* Some tests added (also test where Calcite is exposed via avatica http server
through jdbc)
* Fix for CALCITE-2613 added
* It fixes also CALCITE-2609
Please note, that some issues remains:
* ascii stream, setting blobs as streams, etc - are not supported
> JDBC adapter fails to execute a prepared statement with a bind variable
> ---
>
> Key: CALCITE-563
> URL: https://issues.apache.org/jira/browse/CALCITE-563
> Project: Calcite
> Issue Type: Bug
> Components: jdbc-adapter
>Affects Versions: 1.0.0-incubating
> Environment: Any
>Reporter: Ng Jiunn Jye
>Assignee: Julian Hyde
>Priority: Major
> Labels: newbie
>
> Description:
> Calcite fail to execute PreparedStatement bind variable to external JDBC
> datasource.
> Problem:
> RexCall of kind DYNAMIC_PARAM is not supported in JdbcAdaptor.
> Error StackTrace:
> {noformat}
> java.sql.SQLException: Error while preparing statement [SELECT ID, VALS FROM
> T1 where id = ?]
> at org.apache.calcite.avatica.Helper.createException(Helper.java:39)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.prepareStatement(CalciteConnectionImpl.java:161)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.prepareStatement(CalciteConnectionImpl.java:1)
> at
> org.apache.calcite.avatica.AvaticaConnection.prepareStatement(AvaticaConnection.java:121)
> at
> org.apache.calcite.jdbc.TestPrepareStatementBindVar.main(TestPrepareStatementBindVar.java:48)
> Caused by: java.lang.ClassCastException:
> org.apache.calcite.rex.RexDynamicParam incompatible with
> org.apache.calcite.rex.RexCall
> at
> org.apache.calcite.adapter.jdbc.JdbcImplementor$Context.toSql(JdbcImplementor.java:210)
> at
> org.apache.calcite.adapter.jdbc.JdbcImplementor$Context.toSql(JdbcImplementor.java:268)
> at
> org.apache.calcite.adapter.jdbc.JdbcImplementor$Context.toSql(JdbcImplementor.java:212)
> at
> org.apache.calcite.adapter.jdbc.JdbcRules$JdbcFilter.implement(JdbcRules.java:538)
> at
> org.apache.calcite.adapter.jdbc.JdbcImplementor.visitChild(JdbcImplementor.java:118)
> at
> org.apache.calcite.adapter.jdbc.JdbcToEnumerableConverter.generateSql(JdbcToEnumerableConverter.java:286)
> at
> org.apache.calcite.adapter.jdbc.JdbcToEnumerableConverter.implement(JdbcToEnumerableConverter.java:89)
> at
> org.apache.calcite.adapter.enumerable.EnumerableRelImplementor.implementRoot(EnumerableRelImplementor.java:99)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl$CalcitePreparingStmt.implement(CalcitePrepareImpl.java:867)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:298)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:192)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:486)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:383)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:352)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:174)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.prepareStatement(CalciteConnectionImpl.java:157)
> {noformat}
> Test Code:
> {code:java}
> package org.apache.calcite.jdbc;
> import java.sql.Connection;
> import java.sql.DriverManager;
> import java.sql.PreparedStatement;
> import java.sql.ResultSet;
> import java.sql.Statement;
> import java.util.Properties;
> import org.hsqldb.jdbcDriver;
> public class TestPrepareStatementBindVar {
> public static void main(String[] args) {
> try {
> String hsqldbMemUrl = "jdbc:hsqldb:mem:.";
> Connection baseConnection =
> DriverManager.getConnection(hsqldbMemUrl);
> Statement baseStmt =
> baseConnection.createStatement();
> baseStmt.execute("CREATE TABLE T1 (\n"
> + "ID INTEGER,\n"
> + "VALS INTEGER)");
> baseStmt.execute("INSERT INTO T1 VALUES (1, 1)");
> baseStmt.close();
> baseConnection.commit();
> Properties info = new Properties();
> info.put("model",
> "inline:"
> + "{\n"
> + " version: '1.0',\n"
>
[jira] [Commented] (CALCITE-2609) Dynamic parameters ? pushed to underlying jdbc schema
[ https://issues.apache.org/jira/browse/CALCITE-2609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16679630#comment-16679630 ] Piotr Bojko commented on CALCITE-2609: -- Another fix is here https://github.com/apache/calcite/pull/907 > Dynamic parameters ? pushed to underlying jdbc schema > - > > Key: CALCITE-2609 > URL: https://issues.apache.org/jira/browse/CALCITE-2609 > Project: Calcite > Issue Type: Bug >Affects Versions: 1.17.0 >Reporter: Piotr Bojko >Assignee: Julian Hyde >Priority: Major > > When using PreparedStatement parameters "?" they can be pushed down to jdbc > subschemas which cause an error. > RexDynamicParam should now be pushed to jdbc schema. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-563) JDBC adapter fails to execute a prepared statement with a bind variable
[
https://issues.apache.org/jira/browse/CALCITE-563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16678880#comment-16678880
]
Piotr Bojko commented on CALCITE-563:
-
Here is a working POC
-https://github.com/ptrbojko/calcite/tree/feature/CALCITE-563-started-by-vlsi
More or less working - tests which were broken are still broken.
I've added basic test to check if the POC works. I have one issue with this - I
am assuming which method to call on PreparedStatement based on the type of
dynamic parameter from DataContext and for some types it is not enough, see
PreparedStatement.setASCIIStream vs setBinaryStream.
> JDBC adapter fails to execute a prepared statement with a bind variable
> ---
>
> Key: CALCITE-563
> URL: https://issues.apache.org/jira/browse/CALCITE-563
> Project: Calcite
> Issue Type: Bug
> Components: jdbc-adapter
>Affects Versions: 1.0.0-incubating
> Environment: Any
>Reporter: Ng Jiunn Jye
>Assignee: Julian Hyde
>Priority: Major
> Labels: newbie
>
> Description:
> Calcite fail to execute PreparedStatement bind variable to external JDBC
> datasource.
> Problem:
> RexCall of kind DYNAMIC_PARAM is not supported in JdbcAdaptor.
> Error StackTrace:
> {noformat}
> java.sql.SQLException: Error while preparing statement [SELECT ID, VALS FROM
> T1 where id = ?]
> at org.apache.calcite.avatica.Helper.createException(Helper.java:39)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.prepareStatement(CalciteConnectionImpl.java:161)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.prepareStatement(CalciteConnectionImpl.java:1)
> at
> org.apache.calcite.avatica.AvaticaConnection.prepareStatement(AvaticaConnection.java:121)
> at
> org.apache.calcite.jdbc.TestPrepareStatementBindVar.main(TestPrepareStatementBindVar.java:48)
> Caused by: java.lang.ClassCastException:
> org.apache.calcite.rex.RexDynamicParam incompatible with
> org.apache.calcite.rex.RexCall
> at
> org.apache.calcite.adapter.jdbc.JdbcImplementor$Context.toSql(JdbcImplementor.java:210)
> at
> org.apache.calcite.adapter.jdbc.JdbcImplementor$Context.toSql(JdbcImplementor.java:268)
> at
> org.apache.calcite.adapter.jdbc.JdbcImplementor$Context.toSql(JdbcImplementor.java:212)
> at
> org.apache.calcite.adapter.jdbc.JdbcRules$JdbcFilter.implement(JdbcRules.java:538)
> at
> org.apache.calcite.adapter.jdbc.JdbcImplementor.visitChild(JdbcImplementor.java:118)
> at
> org.apache.calcite.adapter.jdbc.JdbcToEnumerableConverter.generateSql(JdbcToEnumerableConverter.java:286)
> at
> org.apache.calcite.adapter.jdbc.JdbcToEnumerableConverter.implement(JdbcToEnumerableConverter.java:89)
> at
> org.apache.calcite.adapter.enumerable.EnumerableRelImplementor.implementRoot(EnumerableRelImplementor.java:99)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl$CalcitePreparingStmt.implement(CalcitePrepareImpl.java:867)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:298)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:192)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:486)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:383)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:352)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:174)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.prepareStatement(CalciteConnectionImpl.java:157)
> {noformat}
> Test Code:
> {code:java}
> package org.apache.calcite.jdbc;
> import java.sql.Connection;
> import java.sql.DriverManager;
> import java.sql.PreparedStatement;
> import java.sql.ResultSet;
> import java.sql.Statement;
> import java.util.Properties;
> import org.hsqldb.jdbcDriver;
> public class TestPrepareStatementBindVar {
> public static void main(String[] args) {
> try {
> String hsqldbMemUrl = "jdbc:hsqldb:mem:.";
> Connection baseConnection =
> DriverManager.getConnection(hsqldbMemUrl);
> Statement baseStmt =
> baseConnection.createStatement();
> baseStmt.execute("CREATE TABLE T1 (\n"
> + "ID INTEGER,\n"
> + "VALS INTEGER)");
> baseStmt.execute("INSERT INTO T1 VALUES (1, 1)");
> baseStmt.close();
> baseConnection.commit();
> Properties info = new Properties();
> info.put("model",
>
[jira] [Comment Edited] (CALCITE-563) JDBC adapter fails to execute a prepared statement with a bind variable
[
https://issues.apache.org/jira/browse/CALCITE-563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16678384#comment-16678384
]
Piotr Bojko edited comment on CALCITE-563 at 11/7/18 3:28 PM:
--
I've taken the branch from [~vladimirsitnikov]. As for now I've managed to
implement something like this (result of conversion):
{code:java}
org.apache.calcite.DataContext root;
public org.apache.calcite.linq4j.Enumerable bind(final
org.apache.calcite.DataContext root0) {
root = root0;
final org.apache.calcite.linq4j.function.Function1 rowBuilderFactory = new
org.apache.calcite.linq4j.function.Function1() {
public org.apache.calcite.linq4j.function.Function0 apply(final
java.sql.ResultSet resultSet) {
return new org.apache.calcite.linq4j.function.Function0() {
public Object apply() {
try {
final Object[] values = new Object[2];
values[0] = resultSet.getInt(1);
if (resultSet.wasNull()) {
values[0] = null;
}
values[1] = resultSet.getDouble(2);
if (resultSet.wasNull()) {
values[1] = null;
}
return values;
} catch (java.sql.SQLException e) {
throw new RuntimeException(
e);
}
}
}
;
}
public Object apply(final Object resultSet) {
return apply(
(java.sql.ResultSet) resultSet);
}
}
;
final org.apache.calcite.linq4j.function.Function1 preparedStatementConsumer
= new org.apache.calcite.linq4j.function.Function1() {
public java.sql.PreparedStatement apply(final java.sql.PreparedStatement
preparedStatement) {
org.apache.calcite.adapter.jdbc.JdbcPreparedStatementUtils.fillDynamicParameters(new
Integer[] {
0}, root);
return preparedStatement;
}
public Object apply(final Object preparedStatement) {
return apply(
(java.sql.PreparedStatement) preparedStatement);
}
}
;
final org.apache.calcite.linq4j.Enumerable enumerable =
org.apache.calcite.runtime.ResultSetEnumerable.of(((org.apache.calcite.adapter.jdbc.JdbcSchema)
root.getRootSchema().getSubSchema("BASEJDBC").unwrap(org.apache.calcite.adapter.jdbc.JdbcSchema.class)).getDataSource(),
"SELECT *\nFROM \"T3\"\nWHERE \"VALS\" =?", rowBuilderFactory);
return enumerable;
}
public Class getElementType() {
return java.lang.Object[].class;
}
{code}
I will feed ResultSetEnumerable.of with preparedStatementConsumer, adjust the
ResultSetEnumerable.of to created prepared statement if needed (maybe split the
method into old one and new, spark adapter uses it also).
was (Author: ptrbojko):
I've taken the branch from [~vladimirsitnikov]. As for now I've managed to
implement something like this (result of conversion):
{code:java}
org.apache.calcite.DataContext root;
public org.apache.calcite.linq4j.Enumerable bind(final
org.apache.calcite.DataContext root0) {
root = root0;
final org.apache.calcite.linq4j.function.Function1 rowBuilderFactory = new
org.apache.calcite.linq4j.function.Function1() {
public org.apache.calcite.linq4j.function.Function0 apply(final
java.sql.ResultSet resultSet) {
return new org.apache.calcite.linq4j.function.Function0() {
public Object apply() {
try {
final Object[] values = new Object[2];
values[0] = resultSet.getInt(1);
if (resultSet.wasNull()) {
values[0] = null;
}
values[1] = resultSet.getDouble(2);
if (resultSet.wasNull()) {
values[1] = null;
}
return values;
} catch (java.sql.SQLException e) {
throw new RuntimeException(
e);
}
}
}
;
}
public Object apply(final Object resultSet) {
return apply(
(java.sql.ResultSet) resultSet);
}
}
;
final org.apache.calcite.linq4j.function.Function1 preparedStatementConsumer
= new org.apache.calcite.linq4j.function.Function1() {
public java.sql.PreparedStatement apply(final java.sql.PreparedStatement
preparedStatement) {
org.apache.calcite.adapter.jdbc.JdbcPreparedStatementUtils.fillDynamicParameters(new
Integer[] {
0}, root);
return preparedStatement;
}
public Object apply(final Object preparedStatement) {
return apply(
(java.sql.PreparedStatement) preparedStatement);
}
}
;
final org.apache.calcite.linq4j.Enumerable enumerable =
org.apache.calcite.runtime.ResultSetEnumerable.of(((org.apache.calcite.adapter.jdbc.JdbcSchema)
root.getRootSchema().getSubSchema("BASEJDBC").unwrap(org.apache.calcite.adapter.jdbc.JdbcSchema.class)).getDataSource(),
"SELECT *\nFROM \"T3\"\nWHERE \"VALS\" =?", rowBuilderFactory);
return enumerable;
[jira] [Commented] (CALCITE-563) JDBC adapter fails to execute a prepared statement with a bind variable
[
https://issues.apache.org/jira/browse/CALCITE-563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16678384#comment-16678384
]
Piotr Bojko commented on CALCITE-563:
-
I've taken the branch from [~vladimirsitnikov]. As for now I've managed to
implement something like this (result of conversion):
{code:java}
org.apache.calcite.DataContext root;
public org.apache.calcite.linq4j.Enumerable bind(final
org.apache.calcite.DataContext root0) {
root = root0;
final org.apache.calcite.linq4j.function.Function1 rowBuilderFactory = new
org.apache.calcite.linq4j.function.Function1() {
public org.apache.calcite.linq4j.function.Function0 apply(final
java.sql.ResultSet resultSet) {
return new org.apache.calcite.linq4j.function.Function0() {
public Object apply() {
try {
final Object[] values = new Object[2];
values[0] = resultSet.getInt(1);
if (resultSet.wasNull()) {
values[0] = null;
}
values[1] = resultSet.getDouble(2);
if (resultSet.wasNull()) {
values[1] = null;
}
return values;
} catch (java.sql.SQLException e) {
throw new RuntimeException(
e);
}
}
}
;
}
public Object apply(final Object resultSet) {
return apply(
(java.sql.ResultSet) resultSet);
}
}
;
final org.apache.calcite.linq4j.function.Function1 preparedStatementConsumer
= new org.apache.calcite.linq4j.function.Function1() {
public java.sql.PreparedStatement apply(final java.sql.PreparedStatement
preparedStatement) {
org.apache.calcite.adapter.jdbc.JdbcPreparedStatementUtils.fillDynamicParameters(new
Integer[] {
0}, root);
return preparedStatement;
}
public Object apply(final Object preparedStatement) {
return apply(
(java.sql.PreparedStatement) preparedStatement);
}
}
;
final org.apache.calcite.linq4j.Enumerable enumerable =
org.apache.calcite.runtime.ResultSetEnumerable.of(((org.apache.calcite.adapter.jdbc.JdbcSchema)
root.getRootSchema().getSubSchema("BASEJDBC").unwrap(org.apache.calcite.adapter.jdbc.JdbcSchema.class)).getDataSource(),
"SELECT *\nFROM \"T3\"\nWHERE \"VALS\" =?", rowBuilderFactory);
return enumerable;
}
public Class getElementType() {
return java.lang.Object[].class;
}
{code}
> JDBC adapter fails to execute a prepared statement with a bind variable
> ---
>
> Key: CALCITE-563
> URL: https://issues.apache.org/jira/browse/CALCITE-563
> Project: Calcite
> Issue Type: Bug
> Components: jdbc-adapter
>Affects Versions: 1.0.0-incubating
> Environment: Any
>Reporter: Ng Jiunn Jye
>Assignee: Julian Hyde
>Priority: Major
> Labels: newbie
>
> Description:
> Calcite fail to execute PreparedStatement bind variable to external JDBC
> datasource.
> Problem:
> RexCall of kind DYNAMIC_PARAM is not supported in JdbcAdaptor.
> Error StackTrace:
> {noformat}
> java.sql.SQLException: Error while preparing statement [SELECT ID, VALS FROM
> T1 where id = ?]
> at org.apache.calcite.avatica.Helper.createException(Helper.java:39)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.prepareStatement(CalciteConnectionImpl.java:161)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.prepareStatement(CalciteConnectionImpl.java:1)
> at
> org.apache.calcite.avatica.AvaticaConnection.prepareStatement(AvaticaConnection.java:121)
> at
> org.apache.calcite.jdbc.TestPrepareStatementBindVar.main(TestPrepareStatementBindVar.java:48)
> Caused by: java.lang.ClassCastException:
> org.apache.calcite.rex.RexDynamicParam incompatible with
> org.apache.calcite.rex.RexCall
> at
> org.apache.calcite.adapter.jdbc.JdbcImplementor$Context.toSql(JdbcImplementor.java:210)
> at
> org.apache.calcite.adapter.jdbc.JdbcImplementor$Context.toSql(JdbcImplementor.java:268)
> at
> org.apache.calcite.adapter.jdbc.JdbcImplementor$Context.toSql(JdbcImplementor.java:212)
> at
> org.apache.calcite.adapter.jdbc.JdbcRules$JdbcFilter.implement(JdbcRules.java:538)
> at
> org.apache.calcite.adapter.jdbc.JdbcImplementor.visitChild(JdbcImplementor.java:118)
> at
> org.apache.calcite.adapter.jdbc.JdbcToEnumerableConverter.generateSql(JdbcToEnumerableConverter.java:286)
> at
> org.apache.calcite.adapter.jdbc.JdbcToEnumerableConverter.implement(JdbcToEnumerableConverter.java:89)
> at
> org.apache.calcite.adapter.enumerable.EnumerableRelImplementor.implementRoot(EnumerableRelImplementor.java:99)
> at
>
[jira] [Commented] (CALCITE-2609) Dynamic parameters ? pushed to underlying jdbc schema
[ https://issues.apache.org/jira/browse/CALCITE-2609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16678382#comment-16678382 ] Piotr Bojko commented on CALCITE-2609: -- [~vladimirsitnikov] I am on track with this. Will comment further at CALCITE-563 > Dynamic parameters ? pushed to underlying jdbc schema > - > > Key: CALCITE-2609 > URL: https://issues.apache.org/jira/browse/CALCITE-2609 > Project: Calcite > Issue Type: Bug >Affects Versions: 1.17.0 >Reporter: Piotr Bojko >Assignee: Julian Hyde >Priority: Major > > When using PreparedStatement parameters "?" they can be pushed down to jdbc > subschemas which cause an error. > RexDynamicParam should now be pushed to jdbc schema. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2609) Dynamic parameters ? pushed to underlying jdbc schema
[ https://issues.apache.org/jira/browse/CALCITE-2609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16676694#comment-16676694 ] Piotr Bojko commented on CALCITE-2609: -- Let me check this and have some moment to push the CALCITE-2641 further. Then I will try . But hey - if someone can push CALCITE-2609 and/or CALCITE-563 faster then me, that I would be happy :). RexToLixTranslator area is new to me. > Dynamic parameters ? pushed to underlying jdbc schema > - > > Key: CALCITE-2609 > URL: https://issues.apache.org/jira/browse/CALCITE-2609 > Project: Calcite > Issue Type: Bug >Affects Versions: 1.17.0 >Reporter: Piotr Bojko >Assignee: Julian Hyde >Priority: Major > > When using PreparedStatement parameters "?" they can be pushed down to jdbc > subschemas which cause an error. > RexDynamicParam should now be pushed to jdbc schema. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2641) DATE and TIMESTAMP arguments to user-defined table function
[
https://issues.apache.org/jira/browse/CALCITE-2641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16674927#comment-16674927
]
Piotr Bojko commented on CALCITE-2641:
--
I've created a pull https://github.com/apache/calcite/pull/900 and former
https://github.com/apache/calcite/pull/896 .
Please review and choose the better on for further steps :)
> DATE and TIMESTAMP arguments to user-defined table function
> ---
>
> Key: CALCITE-2641
> URL: https://issues.apache.org/jira/browse/CALCITE-2641
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0, 1.18.0
>Reporter: Piotr Bojko
>Assignee: Julian Hyde
>Priority: Major
>
> I am trying to create UDF with java.sql.Timestamp as a parameter:
> {code:java}
> public static QueryableTable getTable(
> @Parameter(name = "Projection") String projection,
> @Parameter(name = "Query") String query,
> @Parameter(name = "Test Timestamp") Timestamp
> timestamp)
> {code}
> But when using following UDF like this:
> {code:java}
> SELECT * FROM TABLE(MYUDF('ID','', TIMESTAMP '2013-01-01 01:01:01'))
> {code}
> I've got following exception and wondering whether I am missing something or
> having date/time as a parameter is not fully supported yet?
> {noformat}
> [INFO] [talledLocalContainer] java.lang.AssertionError: value 2013-01-01
> 01:01:01 does not match type class java.sql.Timestamp
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.ConstantExpression.(ConstantExpression.java:49)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.Expressions.constant(Expressions.java:588)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.OptimizeShuttle.visit(OptimizeShuttle.java:278)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.UnaryExpression.accept(UnaryExpression.java:37)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.GotoStatement.accept(GotoStatement.java:60)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.BlockBuilder.optimize(BlockBuilder.java:438)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.BlockBuilder.toBlock(BlockBuilder.java:322)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlUserDefinedTableMacro.coerce(SqlUserDefinedTableMacro.java:190)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlUserDefinedTableMacro.convertArguments(SqlUserDefinedTableMacro.java:110)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlUserDefinedTableFunction.getRowType(SqlUserDefinedTableFunction.java:70)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.ProcedureNamespace.validateImpl(ProcedureNamespace.java:62)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:971)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:950)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateFrom(SqlValidatorImpl.java:3036)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateFrom(SqlValidatorImpl.java:3018)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3288)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:60)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:971)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:950)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.SqlSelect.validate(SqlSelect.java:216)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:925)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validate(SqlValidatorImpl.java:629)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:553)
>
[jira] [Comment Edited] (CALCITE-2641) DATE and TIMESTAMP arguments to user-defined table function
[
https://issues.apache.org/jira/browse/CALCITE-2641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16674927#comment-16674927
]
Piotr Bojko edited comment on CALCITE-2641 at 11/5/18 10:29 AM:
I've created a pull https://github.com/apache/calcite/pull/900 and former
https://github.com/apache/calcite/pull/896 .
Please review and choose the better one for further steps :)
was (Author: ptrbojko):
I've created a pull https://github.com/apache/calcite/pull/900 and former
https://github.com/apache/calcite/pull/896 .
Please review and choose the better on for further steps :)
> DATE and TIMESTAMP arguments to user-defined table function
> ---
>
> Key: CALCITE-2641
> URL: https://issues.apache.org/jira/browse/CALCITE-2641
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0, 1.18.0
>Reporter: Piotr Bojko
>Assignee: Julian Hyde
>Priority: Major
>
> I am trying to create UDF with java.sql.Timestamp as a parameter:
> {code:java}
> public static QueryableTable getTable(
> @Parameter(name = "Projection") String projection,
> @Parameter(name = "Query") String query,
> @Parameter(name = "Test Timestamp") Timestamp
> timestamp)
> {code}
> But when using following UDF like this:
> {code:java}
> SELECT * FROM TABLE(MYUDF('ID','', TIMESTAMP '2013-01-01 01:01:01'))
> {code}
> I've got following exception and wondering whether I am missing something or
> having date/time as a parameter is not fully supported yet?
> {noformat}
> [INFO] [talledLocalContainer] java.lang.AssertionError: value 2013-01-01
> 01:01:01 does not match type class java.sql.Timestamp
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.ConstantExpression.(ConstantExpression.java:49)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.Expressions.constant(Expressions.java:588)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.OptimizeShuttle.visit(OptimizeShuttle.java:278)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.UnaryExpression.accept(UnaryExpression.java:37)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.GotoStatement.accept(GotoStatement.java:60)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.BlockBuilder.optimize(BlockBuilder.java:438)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.BlockBuilder.toBlock(BlockBuilder.java:322)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlUserDefinedTableMacro.coerce(SqlUserDefinedTableMacro.java:190)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlUserDefinedTableMacro.convertArguments(SqlUserDefinedTableMacro.java:110)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlUserDefinedTableFunction.getRowType(SqlUserDefinedTableFunction.java:70)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.ProcedureNamespace.validateImpl(ProcedureNamespace.java:62)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:971)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:950)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateFrom(SqlValidatorImpl.java:3036)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateFrom(SqlValidatorImpl.java:3018)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3288)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:60)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:971)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:950)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.SqlSelect.validate(SqlSelect.java:216)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:925)
> [INFO]
[jira] [Commented] (CALCITE-2641) DATE and TIMESTAMP arguments to user-defined table function
[
https://issues.apache.org/jira/browse/CALCITE-2641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16668439#comment-16668439
]
Piotr Bojko commented on CALCITE-2641:
--
I've scratched a little patch to RexLixTranslator just to show my understanding
of the approach suggested by [~vladimirsitnikov] . -
https://github.com/ptrbojko/calcite/tree/bug/CALCITE-2641-rexlixtranslator-approach
So now we have a patch (as a pull request) here -
https://github.com/apache/calcite/pull/896 and a second patch (as a branch
because this is a POC, only resolved for Timestamp like cases) -
https://github.com/ptrbojko/calcite/tree/bug/CALCITE-2641-rexlixtranslator-approach
[~vladimirsitnikov] could you help me and decide or suggest who can decide
which approach is better for Calcite? I am willing to ship a fix anyway but it
is up to you, apache folks which way is better. Maybe [~julianhyde] ?
Again, thx for help.
> DATE and TIMESTAMP arguments to user-defined table function
> ---
>
> Key: CALCITE-2641
> URL: https://issues.apache.org/jira/browse/CALCITE-2641
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0, 1.18.0
>Reporter: Piotr Bojko
>Assignee: Julian Hyde
>Priority: Major
>
> I am trying to create UDF with java.sql.Timestamp as a parameter:
> {code:java}
> public static QueryableTable getTable(
> @Parameter(name = "Projection") String projection,
> @Parameter(name = "Query") String query,
> @Parameter(name = "Test Timestamp") Timestamp
> timestamp)
> {code}
> But when using following UDF like this:
> {code:java}
> SELECT * FROM TABLE(MYUDF('ID','', TIMESTAMP '2013-01-01 01:01:01'))
> {code}
> I've got following exception and wondering whether I am missing something or
> having date/time as a parameter is not fully supported yet?
> {noformat}
> [INFO] [talledLocalContainer] java.lang.AssertionError: value 2013-01-01
> 01:01:01 does not match type class java.sql.Timestamp
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.ConstantExpression.(ConstantExpression.java:49)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.Expressions.constant(Expressions.java:588)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.OptimizeShuttle.visit(OptimizeShuttle.java:278)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.UnaryExpression.accept(UnaryExpression.java:37)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.GotoStatement.accept(GotoStatement.java:60)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.BlockBuilder.optimize(BlockBuilder.java:438)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.BlockBuilder.toBlock(BlockBuilder.java:322)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlUserDefinedTableMacro.coerce(SqlUserDefinedTableMacro.java:190)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlUserDefinedTableMacro.convertArguments(SqlUserDefinedTableMacro.java:110)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlUserDefinedTableFunction.getRowType(SqlUserDefinedTableFunction.java:70)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.ProcedureNamespace.validateImpl(ProcedureNamespace.java:62)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:971)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:950)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateFrom(SqlValidatorImpl.java:3036)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateFrom(SqlValidatorImpl.java:3018)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3288)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:60)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:971)
> [INFO] [talledLocalContainer] at
>
[jira] [Commented] (CALCITE-2641) DATE and TIMESTAMP arguments to user-defined table function
[
https://issues.apache.org/jira/browse/CALCITE-2641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16667843#comment-16667843
]
Piotr Bojko commented on CALCITE-2641:
--
[~vladimirsitnikov] Thanks for clarification and hints! This was the exact hint
I was lacking :)
I will look to it and see if I can handle it.
BTW - when you look SqlUserDefinedTableMacro.coerce, following branch:
{code:java}
if (clazz == String.class && o instanceof NlsString) {
return ((NlsString) o).getValue();
}
{code}
This branch looks like it should also be at RexToLixTranslator, am I right?
This branch have deceived me to make my fix.
Again, thx for hint.
> DATE and TIMESTAMP arguments to user-defined table function
> ---
>
> Key: CALCITE-2641
> URL: https://issues.apache.org/jira/browse/CALCITE-2641
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0, 1.18.0
>Reporter: Piotr Bojko
>Assignee: Julian Hyde
>Priority: Major
>
> I am trying to create UDF with java.sql.Timestamp as a parameter:
> {code:java}
> public static QueryableTable getTable(
> @Parameter(name = "Projection") String projection,
> @Parameter(name = "Query") String query,
> @Parameter(name = "Test Timestamp") Timestamp
> timestamp)
> {code}
> But when using following UDF like this:
> {code:java}
> SELECT * FROM TABLE(MYUDF('ID','', TIMESTAMP '2013-01-01 01:01:01'))
> {code}
> I've got following exception and wondering whether I am missing something or
> having date/time as a parameter is not fully supported yet?
> {noformat}
> [INFO] [talledLocalContainer] java.lang.AssertionError: value 2013-01-01
> 01:01:01 does not match type class java.sql.Timestamp
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.ConstantExpression.(ConstantExpression.java:49)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.Expressions.constant(Expressions.java:588)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.OptimizeShuttle.visit(OptimizeShuttle.java:278)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.UnaryExpression.accept(UnaryExpression.java:37)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.GotoStatement.accept(GotoStatement.java:60)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.BlockBuilder.optimize(BlockBuilder.java:438)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.BlockBuilder.toBlock(BlockBuilder.java:322)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlUserDefinedTableMacro.coerce(SqlUserDefinedTableMacro.java:190)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlUserDefinedTableMacro.convertArguments(SqlUserDefinedTableMacro.java:110)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlUserDefinedTableFunction.getRowType(SqlUserDefinedTableFunction.java:70)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.ProcedureNamespace.validateImpl(ProcedureNamespace.java:62)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:971)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:950)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateFrom(SqlValidatorImpl.java:3036)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateFrom(SqlValidatorImpl.java:3018)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3288)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:60)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:971)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:950)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.SqlSelect.validate(SqlSelect.java:216)
> [INFO] [talledLocalContainer] at
>
[jira] [Commented] (CALCITE-2641) DATE and TIMESTAMP arguments to user-defined table function
[
https://issues.apache.org/jira/browse/CALCITE-2641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16667808#comment-16667808
]
Piotr Bojko commented on CALCITE-2641:
--
I've created a pull request for this -
https://github.com/apache/calcite/pull/896 .
[~julianhyde] I know that users should define their functions without knowledge
of Calcite internal mechanics and data types. I rather had some doubts where
the fix should be placed in those internal mechanics.
Anyway - please review whether my fix fits to Calcite design and responsibility
of conversion is at appropriate place :)
> DATE and TIMESTAMP arguments to user-defined table function
> ---
>
> Key: CALCITE-2641
> URL: https://issues.apache.org/jira/browse/CALCITE-2641
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0, 1.18.0
>Reporter: Piotr Bojko
>Assignee: Julian Hyde
>Priority: Major
>
> I am trying to create UDF with java.sql.Timestamp as a parameter:
> {code:java}
> public static QueryableTable getTable(
> @Parameter(name = "Projection") String projection,
> @Parameter(name = "Query") String query,
> @Parameter(name = "Test Timestamp") Timestamp
> timestamp)
> {code}
> But when using following UDF like this:
> {code:java}
> SELECT * FROM TABLE(MYUDF('ID','', TIMESTAMP '2013-01-01 01:01:01'))
> {code}
> I've got following exception and wondering whether I am missing something or
> having date/time as a parameter is not fully supported yet?
> {noformat}
> [INFO] [talledLocalContainer] java.lang.AssertionError: value 2013-01-01
> 01:01:01 does not match type class java.sql.Timestamp
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.ConstantExpression.(ConstantExpression.java:49)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.Expressions.constant(Expressions.java:588)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.OptimizeShuttle.visit(OptimizeShuttle.java:278)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.UnaryExpression.accept(UnaryExpression.java:37)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.GotoStatement.accept(GotoStatement.java:60)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.BlockBuilder.optimize(BlockBuilder.java:438)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.BlockBuilder.toBlock(BlockBuilder.java:322)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlUserDefinedTableMacro.coerce(SqlUserDefinedTableMacro.java:190)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlUserDefinedTableMacro.convertArguments(SqlUserDefinedTableMacro.java:110)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlUserDefinedTableFunction.getRowType(SqlUserDefinedTableFunction.java:70)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.ProcedureNamespace.validateImpl(ProcedureNamespace.java:62)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:971)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:950)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateFrom(SqlValidatorImpl.java:3036)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateFrom(SqlValidatorImpl.java:3018)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3288)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:60)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:971)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:950)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.SqlSelect.validate(SqlSelect.java:216)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:925)
> [INFO]
[jira] [Commented] (CALCITE-2641) DATE and TIMESTAMP arguments to user-defined table function
[
https://issues.apache.org/jira/browse/CALCITE-2641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16667331#comment-16667331
]
Piotr Bojko commented on CALCITE-2641:
--
I would like to have a hint on this. I am willing to ship the patch but I want
to know that enriching TimeString, DateString and Timestampstring with a custom
interface to take a responsibility for conversion to appropriate
Date/Time/Timestamp is a good path in terms of a Calcite design.
Conversion of different types in different scenarios seems to be pretty
scattered across the code and I don't want to take things worse.
> DATE and TIMESTAMP arguments to user-defined table function
> ---
>
> Key: CALCITE-2641
> URL: https://issues.apache.org/jira/browse/CALCITE-2641
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0, 1.18.0
>Reporter: Piotr Bojko
>Assignee: Julian Hyde
>Priority: Major
>
> I am trying to create UDF with java.sql.Timestamp as a parameter:
> {code:java}
> public static QueryableTable getTable(
> @Parameter(name = "Projection") String projection,
> @Parameter(name = "Query") String query,
> @Parameter(name = "Test Timestamp") Timestamp
> timestamp)
> {code}
> But when using following UDF like this:
> {code:java}
> SELECT * FROM TABLE(MYUDF('ID','', TIMESTAMP '2013-01-01 01:01:01'))
> {code}
> I've got following exception and wondering whether I am missing something or
> having date/time as a parameter is not fully supported yet?
> {noformat}
> [INFO] [talledLocalContainer] java.lang.AssertionError: value 2013-01-01
> 01:01:01 does not match type class java.sql.Timestamp
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.ConstantExpression.(ConstantExpression.java:49)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.Expressions.constant(Expressions.java:588)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.OptimizeShuttle.visit(OptimizeShuttle.java:278)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.UnaryExpression.accept(UnaryExpression.java:37)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.GotoStatement.accept(GotoStatement.java:60)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.BlockBuilder.optimize(BlockBuilder.java:438)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.BlockBuilder.toBlock(BlockBuilder.java:322)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlUserDefinedTableMacro.coerce(SqlUserDefinedTableMacro.java:190)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlUserDefinedTableMacro.convertArguments(SqlUserDefinedTableMacro.java:110)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlUserDefinedTableFunction.getRowType(SqlUserDefinedTableFunction.java:70)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.ProcedureNamespace.validateImpl(ProcedureNamespace.java:62)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:971)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:950)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateFrom(SqlValidatorImpl.java:3036)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateFrom(SqlValidatorImpl.java:3018)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3288)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:60)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:971)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:950)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.SqlSelect.validate(SqlSelect.java:216)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:925)
> [INFO]
[jira] [Comment Edited] (CALCITE-2641) DATE and TIMESTAMP arguments to user-defined table function
[
https://issues.apache.org/jira/browse/CALCITE-2641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16664268#comment-16664268
]
Piotr Bojko edited comment on CALCITE-2641 at 10/25/18 8:59 PM:
It seems that TimeString, DateString and Timestampstring are not matchable with
Date, Time and Timestamp classes on the Expressions class, method
ConstantExpression constant(Object value, Type type) .
Maybe they could implement simple
{code:java}
interface ToTypeConvertible {
Type getConvertibleType();
Object convert();
}
{code}
Then appropriate branch in Expressions.constant(Object value, Type type) can be
easily done.
Although I am not really sure why Date/Time/TimestampString classes are needed
in calcite.
was (Author: ptrbojko):
It seems that TimeString, DateString and Timestring are not matchable with
Date, Time and Timestamp classes on the Expressions class, method
ConstantExpression constant(Object value, Type type) .
Maybe they could implement simple
{code:java}
interface ToTypeConvertible {
Type getConvertibleType();
Object convert();
}
{code}
Then appropriate branch in Expressions.constant(Object value, Type type) can be
easily done.
> DATE and TIMESTAMP arguments to user-defined table function
> ---
>
> Key: CALCITE-2641
> URL: https://issues.apache.org/jira/browse/CALCITE-2641
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0, 1.18.0
>Reporter: Piotr Bojko
>Assignee: Julian Hyde
>Priority: Major
>
> I am trying to create UDF with java.sql.Timestamp as a parameter:
> {code:java}
> public static QueryableTable getTable(
> @Parameter(name = "Projection") String projection,
> @Parameter(name = "Query") String query,
> @Parameter(name = "Test Timestamp") Timestamp
> timestamp)
> {code}
> But when using following UDF like this:
> {code:java}
> SELECT * FROM TABLE(MYUDF('ID','', TIMESTAMP '2013-01-01 01:01:01'))
> {code}
> I've got following exception and wondering whether I am missing something or
> having date/time as a parameter is not fully supported yet?
> {noformat}
> [INFO] [talledLocalContainer] java.lang.AssertionError: value 2013-01-01
> 01:01:01 does not match type class java.sql.Timestamp
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.ConstantExpression.(ConstantExpression.java:49)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.Expressions.constant(Expressions.java:588)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.OptimizeShuttle.visit(OptimizeShuttle.java:278)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.UnaryExpression.accept(UnaryExpression.java:37)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.GotoStatement.accept(GotoStatement.java:60)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.BlockBuilder.optimize(BlockBuilder.java:438)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.BlockBuilder.toBlock(BlockBuilder.java:322)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlUserDefinedTableMacro.coerce(SqlUserDefinedTableMacro.java:190)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlUserDefinedTableMacro.convertArguments(SqlUserDefinedTableMacro.java:110)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlUserDefinedTableFunction.getRowType(SqlUserDefinedTableFunction.java:70)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.ProcedureNamespace.validateImpl(ProcedureNamespace.java:62)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:971)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:950)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateFrom(SqlValidatorImpl.java:3036)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateFrom(SqlValidatorImpl.java:3018)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3288)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:60)
> [INFO] [talledLocalContainer] at
>
[jira] [Commented] (CALCITE-2641) DATE and TIMESTAMP arguments to user-defined table function
[
https://issues.apache.org/jira/browse/CALCITE-2641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16664268#comment-16664268
]
Piotr Bojko commented on CALCITE-2641:
--
It seems that TimeString, DateString and Timestring are not matchable with
Date, Time and Timestamp classes on the Expressions class, method
ConstantExpression constant(Object value, Type type) .
Maybe they could implement simple
{code:java}
interface ToTypeConvertible {
Type getConvertibleType();
Object convert();
}
{code}
Then appropriate branch in Expressions.constant(Object value, Type type) can be
easily done.
> DATE and TIMESTAMP arguments to user-defined table function
> ---
>
> Key: CALCITE-2641
> URL: https://issues.apache.org/jira/browse/CALCITE-2641
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0, 1.18.0
>Reporter: Piotr Bojko
>Assignee: Julian Hyde
>Priority: Major
>
> I am trying to create UDF with java.sql.Timestamp as a parameter:
> {code:java}
> public static QueryableTable getTable(
> @Parameter(name = "Projection") String projection,
> @Parameter(name = "Query") String query,
> @Parameter(name = "Test Timestamp") Timestamp
> timestamp)
> {code}
> But when using following UDF like this:
> {code:java}
> SELECT * FROM TABLE(MYUDF('ID','', TIMESTAMP '2013-01-01 01:01:01'))
> {code}
> I've got following exception and wondering whether I am missing something or
> having date/time as a parameter is not fully supported yet?
> {noformat}
> [INFO] [talledLocalContainer] java.lang.AssertionError: value 2013-01-01
> 01:01:01 does not match type class java.sql.Timestamp
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.ConstantExpression.(ConstantExpression.java:49)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.Expressions.constant(Expressions.java:588)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.OptimizeShuttle.visit(OptimizeShuttle.java:278)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.UnaryExpression.accept(UnaryExpression.java:37)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.GotoStatement.accept(GotoStatement.java:60)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.BlockBuilder.optimize(BlockBuilder.java:438)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.BlockBuilder.toBlock(BlockBuilder.java:322)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlUserDefinedTableMacro.coerce(SqlUserDefinedTableMacro.java:190)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlUserDefinedTableMacro.convertArguments(SqlUserDefinedTableMacro.java:110)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlUserDefinedTableFunction.getRowType(SqlUserDefinedTableFunction.java:70)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.ProcedureNamespace.validateImpl(ProcedureNamespace.java:62)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:971)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:950)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateFrom(SqlValidatorImpl.java:3036)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateFrom(SqlValidatorImpl.java:3018)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3288)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:60)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:971)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:950)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.SqlSelect.validate(SqlSelect.java:216)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:925)
> [INFO]
[jira] [Commented] (CALCITE-2641) DATE and TIMESTAMP arguments to user-defined table function
[
https://issues.apache.org/jira/browse/CALCITE-2641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16664255#comment-16664255
]
Piotr Bojko commented on CALCITE-2641:
--
Suggestion from [~vladimirsitnikov] about
org/apache/calcite/linq4j/tree/OptimizeShuttle.java:277 does not seem to work .
> DATE and TIMESTAMP arguments to user-defined table function
> ---
>
> Key: CALCITE-2641
> URL: https://issues.apache.org/jira/browse/CALCITE-2641
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0, 1.18.0
>Reporter: Piotr Bojko
>Assignee: Julian Hyde
>Priority: Major
>
> I am trying to create UDF with java.sql.Timestamp as a parameter:
> {code:java}
> public static QueryableTable getTable(
> @Parameter(name = "Projection") String projection,
> @Parameter(name = "Query") String query,
> @Parameter(name = "Test Timestamp") Timestamp
> timestamp)
> {code}
> But when using following UDF like this:
> {code:java}
> SELECT * FROM TABLE(MYUDF('ID','', TIMESTAMP '2013-01-01 01:01:01'))
> {code}
> I've got following exception and wondering whether I am missing something or
> having date/time as a parameter is not fully supported yet?
> {noformat}
> [INFO] [talledLocalContainer] java.lang.AssertionError: value 2013-01-01
> 01:01:01 does not match type class java.sql.Timestamp
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.ConstantExpression.(ConstantExpression.java:49)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.Expressions.constant(Expressions.java:588)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.OptimizeShuttle.visit(OptimizeShuttle.java:278)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.UnaryExpression.accept(UnaryExpression.java:37)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.GotoStatement.accept(GotoStatement.java:60)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.BlockBuilder.optimize(BlockBuilder.java:438)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.BlockBuilder.toBlock(BlockBuilder.java:322)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlUserDefinedTableMacro.coerce(SqlUserDefinedTableMacro.java:190)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlUserDefinedTableMacro.convertArguments(SqlUserDefinedTableMacro.java:110)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlUserDefinedTableFunction.getRowType(SqlUserDefinedTableFunction.java:70)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.ProcedureNamespace.validateImpl(ProcedureNamespace.java:62)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:971)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:950)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateFrom(SqlValidatorImpl.java:3036)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateFrom(SqlValidatorImpl.java:3018)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3288)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:60)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:971)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:950)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.SqlSelect.validate(SqlSelect.java:216)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:925)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validate(SqlValidatorImpl.java:629)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:553)
> [INFO] [talledLocalContainer] at
>
[jira] [Commented] (CALCITE-2641) DATE and TIMESTAMP arguments to user-defined table function
[
https://issues.apache.org/jira/browse/CALCITE-2641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16664250#comment-16664250
]
Piotr Bojko commented on CALCITE-2641:
--
Here is a [test case|https://github.com/ptrbojko/calcite/tree/bug/CALCITE-2641].
> DATE and TIMESTAMP arguments to user-defined table function
> ---
>
> Key: CALCITE-2641
> URL: https://issues.apache.org/jira/browse/CALCITE-2641
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0, 1.18.0
>Reporter: Piotr Bojko
>Assignee: Julian Hyde
>Priority: Major
>
> I am trying to create UDF with java.sql.Timestamp as a parameter:
> {code:java}
> public static QueryableTable getTable(
> @Parameter(name = "Projection") String projection,
> @Parameter(name = "Query") String query,
> @Parameter(name = "Test Timestamp") Timestamp
> timestamp)
> {code}
> But when using following UDF like this:
> {code:java}
> SELECT * FROM TABLE(MYUDF('ID','', TIMESTAMP '2013-01-01 01:01:01'))
> {code}
> I've got following exception and wondering whether I am missing something or
> having date/time as a parameter is not fully supported yet?
> {noformat}
> [INFO] [talledLocalContainer] java.lang.AssertionError: value 2013-01-01
> 01:01:01 does not match type class java.sql.Timestamp
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.ConstantExpression.(ConstantExpression.java:49)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.Expressions.constant(Expressions.java:588)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.OptimizeShuttle.visit(OptimizeShuttle.java:278)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.UnaryExpression.accept(UnaryExpression.java:37)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.GotoStatement.accept(GotoStatement.java:60)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.BlockBuilder.optimize(BlockBuilder.java:438)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.BlockBuilder.toBlock(BlockBuilder.java:322)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlUserDefinedTableMacro.coerce(SqlUserDefinedTableMacro.java:190)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlUserDefinedTableMacro.convertArguments(SqlUserDefinedTableMacro.java:110)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlUserDefinedTableFunction.getRowType(SqlUserDefinedTableFunction.java:70)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.ProcedureNamespace.validateImpl(ProcedureNamespace.java:62)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:971)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:950)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateFrom(SqlValidatorImpl.java:3036)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateFrom(SqlValidatorImpl.java:3018)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3288)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:60)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:971)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:950)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.SqlSelect.validate(SqlSelect.java:216)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:925)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validate(SqlValidatorImpl.java:629)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:553)
> [INFO] [talledLocalContainer] at
>
[jira] [Created] (CALCITE-2641) DATE and TIMESTAMP arguments to user-defined table function
Piotr Bojko created CALCITE-2641:
Summary: DATE and TIMESTAMP arguments to user-defined table
function
Key: CALCITE-2641
URL: https://issues.apache.org/jira/browse/CALCITE-2641
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.17.0, 1.18.0
Reporter: Piotr Bojko
Assignee: Julian Hyde
I am trying to create UDF with java.sql.Timestamp as a parameter:
{code:java}
public static QueryableTable getTable(
@Parameter(name = "Projection") String projection,
@Parameter(name = "Query") String query,
@Parameter(name = "Test Timestamp") Timestamp
timestamp)
{code}
But when using following UDF like this:
{code:java}
SELECT * FROM TABLE(MYUDF('ID','', TIMESTAMP '2013-01-01 01:01:01'))
{code}
I've got following exception and wondering whether I am missing something or
having date/time as a parameter is not fully supported yet?
{noformat}
[INFO] [talledLocalContainer] java.lang.AssertionError: value 2013-01-01
01:01:01 does not match type class java.sql.Timestamp
[INFO] [talledLocalContainer] at
org.apache.calcite.linq4j.tree.ConstantExpression.(ConstantExpression.java:49)
[INFO] [talledLocalContainer] at
org.apache.calcite.linq4j.tree.Expressions.constant(Expressions.java:588)
[INFO] [talledLocalContainer] at
org.apache.calcite.linq4j.tree.OptimizeShuttle.visit(OptimizeShuttle.java:278)
[INFO] [talledLocalContainer] at
org.apache.calcite.linq4j.tree.UnaryExpression.accept(UnaryExpression.java:37)
[INFO] [talledLocalContainer] at
org.apache.calcite.linq4j.tree.GotoStatement.accept(GotoStatement.java:60)
[INFO] [talledLocalContainer] at
org.apache.calcite.linq4j.tree.BlockBuilder.optimize(BlockBuilder.java:438)
[INFO] [talledLocalContainer] at
org.apache.calcite.linq4j.tree.BlockBuilder.toBlock(BlockBuilder.java:322)
[INFO] [talledLocalContainer] at
org.apache.calcite.sql.validate.SqlUserDefinedTableMacro.coerce(SqlUserDefinedTableMacro.java:190)
[INFO] [talledLocalContainer] at
org.apache.calcite.sql.validate.SqlUserDefinedTableMacro.convertArguments(SqlUserDefinedTableMacro.java:110)
[INFO] [talledLocalContainer] at
org.apache.calcite.sql.validate.SqlUserDefinedTableFunction.getRowType(SqlUserDefinedTableFunction.java:70)
[INFO] [talledLocalContainer] at
org.apache.calcite.sql.validate.ProcedureNamespace.validateImpl(ProcedureNamespace.java:62)
[INFO] [talledLocalContainer] at
org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84)
[INFO] [talledLocalContainer] at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:971)
[INFO] [talledLocalContainer] at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:950)
[INFO] [talledLocalContainer] at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateFrom(SqlValidatorImpl.java:3036)
[INFO] [talledLocalContainer] at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateFrom(SqlValidatorImpl.java:3018)
[INFO] [talledLocalContainer] at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3288)
[INFO] [talledLocalContainer] at
org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:60)
[INFO] [talledLocalContainer] at
org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84)
[INFO] [talledLocalContainer] at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:971)
[INFO] [talledLocalContainer] at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:950)
[INFO] [talledLocalContainer] at
org.apache.calcite.sql.SqlSelect.validate(SqlSelect.java:216)
[INFO] [talledLocalContainer] at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:925)
[INFO] [talledLocalContainer] at
org.apache.calcite.sql.validate.SqlValidatorImpl.validate(SqlValidatorImpl.java:629)
[INFO] [talledLocalContainer] at
org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:553)
[INFO] [talledLocalContainer] at
org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:264)
[INFO] [talledLocalContainer] at
org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:230)
[INFO] [talledLocalContainer] at
org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:774)
[INFO] [talledLocalContainer] at
org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:638)
[INFO] [talledLocalContainer] at
org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:608)
[INFO] [talledLocalContainer] at
org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:238)
[INFO]
[jira] [Commented] (CALCITE-2609) Dynamic parameters ? pushed to underlying jdbc schema
[ https://issues.apache.org/jira/browse/CALCITE-2609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16641763#comment-16641763 ] Piotr Bojko commented on CALCITE-2609: -- I've seen it now. Thank you. I understand that you want to push dynamic/bindable down to underlying jdbc shemas, eventually. My thinking is as follows. There is a fix and there is an optimization. My simple change fixes the bug and extends support for bindable parameters to more workinig cases. If anyone is willing to deliver an optimization described in CALCITE-563, then its work interferes with my fix in two ways: # One will remove a fix - this is a simple removal, considering that optimization will change JdbcRules anyway. # One will have more tests already to guard Calcite stability when working on an optimization. As for me I would go with my fix and then plan the optimization, but I am not an active Calcite maintainer - this is only my suggestion. It is solely up to you guys :) > Dynamic parameters ? pushed to underlying jdbc schema > - > > Key: CALCITE-2609 > URL: https://issues.apache.org/jira/browse/CALCITE-2609 > Project: Calcite > Issue Type: Bug >Affects Versions: 1.17.0 >Reporter: Piotr Bojko >Assignee: Julian Hyde >Priority: Major > > When using PreparedStatement parameters "?" they can be pushed down to jdbc > subschemas which cause an error. > RexDynamicParam should no be pushed to jdbc schema. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2613) NPE when Avatica used as JDBC transport for Calcite and dynamic param ? used
[
https://issues.apache.org/jira/browse/CALCITE-2613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16641697#comment-16641697
]
Piotr Bojko commented on CALCITE-2613:
--
I've pushed the fix in https://github.com/apache/calcite/pull/878
> NPE when Avatica used as JDBC transport for Calcite and dynamic param ? used
> --
>
> Key: CALCITE-2613
> URL: https://issues.apache.org/jira/browse/CALCITE-2613
> Project: Calcite
> Issue Type: Bug
> Components: avatica, core
>Affects Versions: 1.17.0, avatica-1.12.0, 1.18.0
>Reporter: Piotr Bojko
>Priority: Major
>
> This is a follow from dev@apache forum discussion. When avatica is wrapping
> through JdbcMeta a calcite connection and prepared statement contains dynamic
> parameters, then AvaticaParameters.toProto throws NPE (underlying Builder of
> Common.AvaticaParameter to be exact).
> FYI [~elserj]
> I will attach a test case to this issue in a sec.
> {quote}
> An AvaticaParameter with a null classname sounds wrong to me. We should
> know the type (per the schema) for some variable, regardless of whether
> or not it is nullable.
> If you can put together a unit test showing what you're seeing in
> Avatica, that would go an extremely long way. It may also just be
> something Calcite is doing which should be corrected (so, a unit test
> there would be a starting point, too).
> Feel free to ping me on Jira. Thanks Piotr!
> On 10/4/18 9:08 AM, ptr.bo...@gmail.com wrote:
> > I've logged a JIRA for the first bug, with a fix proposal -
> > https://issues.apache.org/jira/browse/CALCITE-2609.
> >
> > But the case with AvaticaParameter NPE still remains unclear for me - in
> > terms of design. Help needed :)
> >
> > On Wed, Oct 3, 2018 at 4:14 PM ptr.bo...@gmail.com
> > wrote:
> >
> >> As for the nulls in AvaticaParameter class - I believe this is how calcite
> >> works. For example for the following query *"select * from filters where
> >> name = ?"* - despite the definition of filters table - Calcite will
> >> create org.apache.calcite.avatica.AvaticaParameter with nullable className.
> >>
> >> My case with more details is following: based on calcite-avatica/sever
> >> I've created a mini jdbc server (servlet) exposing Calcite connection with
> >> my custom schemas. I would like to expose my domain as an SQL database so
> >> with Calcite as an engine and domain translation and Avatica as a JDBC
> >> implementor the resulting implementation is very elegant and works great.
> >>
> >> However the same query *"select * from filters where name = ?" *run
> >> through avatica jdbc implementation is resulting NPE
> >> in Common.AvaticaParameter AvaticaParameter.toProto().
> >>
> >> On Wed, Oct 3, 2018 at 12:46 AM Josh Elser wrote:
> >>
> >>> re: nulls on className, that's how Protobuf itself works. You can't set
> >>> null for an attribute.
> >>>
> >>> What is the circumstance where you would have a null className on an
> >>> AvaticaParameter?
> >>>
> >>> We could proactively check in the constructor to AvaticaParameter that
> >>> you don't provide null arguments, but that could be argued in either
> >>> direction (e.g. you should not provide null arguments in the first place).
> >>>
> >>> On 10/2/18 5:11 PM, ptr.bo...@gmail.com wrote:
> Hello,
>
> It seems that my case consists of two bugs:
>
> First one is similar to what I've already patched twice - Calcite pushes
> too much to underlying jdbc schema, in this case "?" operator. Resulting
> subquery onto jdbc schema ends with error about it (? not resolved).
> >>> This
> one belongs to Calcite.
>
> The second one is located
> at org.apache.calcite.avatica.AvaticaParameter.toProto method.
> AvaticaParameter can be a live nullable className but
> Common.AvaticaParameter does not allow to set nulls on className.
> >>> toProto
> method - please verify me - should be more carefull about it and not set
> className on a builder when it is null. This one belongs to Avatica.
>
> If anyone has time to check me it would be great. I will log then each
> >>> bug
> to appropriate apache project in Jira. I should patch first one fairly
> >>> easy.
>
> Regards,
> Piotr
>
> On Mon, Oct 1, 2018 at 1:50 PM Francis Chuang
> wrote:
>
> > Hey Piotr,
> >
> > Thanks for reporting this! I am not familiar with Avatica's internals,
> > so can't recommend how this can be fixed. However, I would suggest
> > writing a test case to reproduce the problem in the meantime.
> >
> > Francis
> >
> > On 1/10/2018 8:59 PM, ptr.bo...@gmail.com wrote:
> >> Hello fellow calcite dev team :)
> >>
> >> I have discovered the case with NPE when trying
[jira] [Commented] (CALCITE-2609) Dynamic parameters ? pushed to underlying jdbc schema
[ https://issues.apache.org/jira/browse/CALCITE-2609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16641699#comment-16641699 ] Piotr Bojko commented on CALCITE-2609: -- I've pushed the proposed fix here - https://github.com/apache/calcite/pull/878 > Dynamic parameters ? pushed to underlying jdbc schema > - > > Key: CALCITE-2609 > URL: https://issues.apache.org/jira/browse/CALCITE-2609 > Project: Calcite > Issue Type: Bug >Affects Versions: 1.17.0, 1.18.0 >Reporter: Piotr Bojko >Assignee: Julian Hyde >Priority: Major > > When using PreparedStatement parameters "?" they can be pushed down to jdbc > subschemas which cause an error. > RexDynamicParam should no be pushed to jdbc schema. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2613) NPE when Avatica used as JDBC transport for Calcite and dynamic param ? used
[
https://issues.apache.org/jira/browse/CALCITE-2613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16641567#comment-16641567
]
Piotr Bojko edited comment on CALCITE-2613 at 10/8/18 9:13 AM:
---
[~elserj] I've found the issue, probably in Calcite as you have said.
org.apache.calcite.prepare.CalcitePrepareImpl.getClassName is not implemented
and when I've stubbed it with a simple String.class - all went fluently well.
Who is the most suitable to advice how to patch that method in calcite? I am
willing to ship the fix, but need guidance.
was (Author: ptrbojko):
[~elserj] I've the issue, probably in Calcite as you have said.
org.apache.calcite.prepare.CalcitePrepareImpl.getClassName is not implemented
and when I've stubbed it with a simple String.class - all went fluently well.
Who is the most suitable to advice how to patch that method in calcite? I am
willing to ship the fix, but need guidance.
> NPE when Avatica used as JDBC transport for Calcite and dynamic param ? used
> --
>
> Key: CALCITE-2613
> URL: https://issues.apache.org/jira/browse/CALCITE-2613
> Project: Calcite
> Issue Type: Bug
> Components: avatica, core
>Affects Versions: 1.17.0, avatica-1.12.0, 1.18.0
>Reporter: Piotr Bojko
>Priority: Major
>
> This is a follow from dev@apache forum discussion. When avatica is wrapping
> through JdbcMeta a calcite connection and prepared statement contains dynamic
> parameters, then AvaticaParameters.toProto throws NPE (underlying Builder of
> Common.AvaticaParameter to be exact).
> FYI [~elserj]
> I will attach a test case to this issue in a sec.
> {quote}
> An AvaticaParameter with a null classname sounds wrong to me. We should
> know the type (per the schema) for some variable, regardless of whether
> or not it is nullable.
> If you can put together a unit test showing what you're seeing in
> Avatica, that would go an extremely long way. It may also just be
> something Calcite is doing which should be corrected (so, a unit test
> there would be a starting point, too).
> Feel free to ping me on Jira. Thanks Piotr!
> On 10/4/18 9:08 AM, ptr.bo...@gmail.com wrote:
> > I've logged a JIRA for the first bug, with a fix proposal -
> > https://issues.apache.org/jira/browse/CALCITE-2609.
> >
> > But the case with AvaticaParameter NPE still remains unclear for me - in
> > terms of design. Help needed :)
> >
> > On Wed, Oct 3, 2018 at 4:14 PM ptr.bo...@gmail.com
> > wrote:
> >
> >> As for the nulls in AvaticaParameter class - I believe this is how calcite
> >> works. For example for the following query *"select * from filters where
> >> name = ?"* - despite the definition of filters table - Calcite will
> >> create org.apache.calcite.avatica.AvaticaParameter with nullable className.
> >>
> >> My case with more details is following: based on calcite-avatica/sever
> >> I've created a mini jdbc server (servlet) exposing Calcite connection with
> >> my custom schemas. I would like to expose my domain as an SQL database so
> >> with Calcite as an engine and domain translation and Avatica as a JDBC
> >> implementor the resulting implementation is very elegant and works great.
> >>
> >> However the same query *"select * from filters where name = ?" *run
> >> through avatica jdbc implementation is resulting NPE
> >> in Common.AvaticaParameter AvaticaParameter.toProto().
> >>
> >> On Wed, Oct 3, 2018 at 12:46 AM Josh Elser wrote:
> >>
> >>> re: nulls on className, that's how Protobuf itself works. You can't set
> >>> null for an attribute.
> >>>
> >>> What is the circumstance where you would have a null className on an
> >>> AvaticaParameter?
> >>>
> >>> We could proactively check in the constructor to AvaticaParameter that
> >>> you don't provide null arguments, but that could be argued in either
> >>> direction (e.g. you should not provide null arguments in the first place).
> >>>
> >>> On 10/2/18 5:11 PM, ptr.bo...@gmail.com wrote:
> Hello,
>
> It seems that my case consists of two bugs:
>
> First one is similar to what I've already patched twice - Calcite pushes
> too much to underlying jdbc schema, in this case "?" operator. Resulting
> subquery onto jdbc schema ends with error about it (? not resolved).
> >>> This
> one belongs to Calcite.
>
> The second one is located
> at org.apache.calcite.avatica.AvaticaParameter.toProto method.
> AvaticaParameter can be a live nullable className but
> Common.AvaticaParameter does not allow to set nulls on className.
> >>> toProto
> method - please verify me - should be more carefull about it and not set
> className on a builder when it is null. This one belongs to Avatica.
>
> If anyone has time to check me it
[jira] [Commented] (CALCITE-2613) NPE when Avatica used as JDBC transport for Calcite and dynamic param ? used
[
https://issues.apache.org/jira/browse/CALCITE-2613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16641567#comment-16641567
]
Piotr Bojko commented on CALCITE-2613:
--
[~elserj] I've the issue, probably in Calcite as you have said.
org.apache.calcite.prepare.CalcitePrepareImpl.getClassName is not implemented
and when I've stubbed it with a simple String.class - all went fluently well.
Who is the most suitable to advice how to patch that method in calcite? I am
willing to ship the fix, but need guidance.
> NPE when Avatica used as JDBC transport for Calcite and dynamic param ? used
> --
>
> Key: CALCITE-2613
> URL: https://issues.apache.org/jira/browse/CALCITE-2613
> Project: Calcite
> Issue Type: Bug
> Components: avatica, core
>Affects Versions: 1.17.0, avatica-1.12.0, 1.18.0
>Reporter: Piotr Bojko
>Priority: Major
>
> This is a follow from dev@apache forum discussion. When avatica is wrapping
> through JdbcMeta a calcite connection and prepared statement contains dynamic
> parameters, then AvaticaParameters.toProto throws NPE (underlying Builder of
> Common.AvaticaParameter to be exact).
> FYI [~elserj]
> I will attach a test case to this issue in a sec.
> {quote}
> An AvaticaParameter with a null classname sounds wrong to me. We should
> know the type (per the schema) for some variable, regardless of whether
> or not it is nullable.
> If you can put together a unit test showing what you're seeing in
> Avatica, that would go an extremely long way. It may also just be
> something Calcite is doing which should be corrected (so, a unit test
> there would be a starting point, too).
> Feel free to ping me on Jira. Thanks Piotr!
> On 10/4/18 9:08 AM, ptr.bo...@gmail.com wrote:
> > I've logged a JIRA for the first bug, with a fix proposal -
> > https://issues.apache.org/jira/browse/CALCITE-2609.
> >
> > But the case with AvaticaParameter NPE still remains unclear for me - in
> > terms of design. Help needed :)
> >
> > On Wed, Oct 3, 2018 at 4:14 PM ptr.bo...@gmail.com
> > wrote:
> >
> >> As for the nulls in AvaticaParameter class - I believe this is how calcite
> >> works. For example for the following query *"select * from filters where
> >> name = ?"* - despite the definition of filters table - Calcite will
> >> create org.apache.calcite.avatica.AvaticaParameter with nullable className.
> >>
> >> My case with more details is following: based on calcite-avatica/sever
> >> I've created a mini jdbc server (servlet) exposing Calcite connection with
> >> my custom schemas. I would like to expose my domain as an SQL database so
> >> with Calcite as an engine and domain translation and Avatica as a JDBC
> >> implementor the resulting implementation is very elegant and works great.
> >>
> >> However the same query *"select * from filters where name = ?" *run
> >> through avatica jdbc implementation is resulting NPE
> >> in Common.AvaticaParameter AvaticaParameter.toProto().
> >>
> >> On Wed, Oct 3, 2018 at 12:46 AM Josh Elser wrote:
> >>
> >>> re: nulls on className, that's how Protobuf itself works. You can't set
> >>> null for an attribute.
> >>>
> >>> What is the circumstance where you would have a null className on an
> >>> AvaticaParameter?
> >>>
> >>> We could proactively check in the constructor to AvaticaParameter that
> >>> you don't provide null arguments, but that could be argued in either
> >>> direction (e.g. you should not provide null arguments in the first place).
> >>>
> >>> On 10/2/18 5:11 PM, ptr.bo...@gmail.com wrote:
> Hello,
>
> It seems that my case consists of two bugs:
>
> First one is similar to what I've already patched twice - Calcite pushes
> too much to underlying jdbc schema, in this case "?" operator. Resulting
> subquery onto jdbc schema ends with error about it (? not resolved).
> >>> This
> one belongs to Calcite.
>
> The second one is located
> at org.apache.calcite.avatica.AvaticaParameter.toProto method.
> AvaticaParameter can be a live nullable className but
> Common.AvaticaParameter does not allow to set nulls on className.
> >>> toProto
> method - please verify me - should be more carefull about it and not set
> className on a builder when it is null. This one belongs to Avatica.
>
> If anyone has time to check me it would be great. I will log then each
> >>> bug
> to appropriate apache project in Jira. I should patch first one fairly
> >>> easy.
>
> Regards,
> Piotr
>
> On Mon, Oct 1, 2018 at 1:50 PM Francis Chuang
> wrote:
>
> > Hey Piotr,
> >
> > Thanks for reporting this! I am not familiar with Avatica's internals,
> > so can't recommend how this can be fixed. However, I
[jira] [Comment Edited] (CALCITE-2613) NPE when Avatica used as JDBC transport for Calcite and dynamic param ? used
[
https://issues.apache.org/jira/browse/CALCITE-2613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16639919#comment-16639919
]
Piotr Bojko edited comment on CALCITE-2613 at 10/5/18 2:58 PM:
---
I am not judging where the problem is placed :) It is even possible that I've
connecting calcite and avatica wrong (although I am using examples from
avatica-server tests and passing calcite like url to the database in meta)
I've debug the whole test and internally avatica throws NPE as follows - it
doesn't catch it nor log it nowhere to be found easily :(
{code}
java.lang.NullPointerException
at
org.apache.calcite.avatica.proto.Common$AvaticaParameter$Builder.setClassName(Common.java:9040)
at
org.apache.calcite.avatica.AvaticaParameter.toProto(AvaticaParameter.java:64)
at org.apache.calcite.avatica.Meta$Signature.toProto(Meta.java:835)
at
org.apache.calcite.avatica.Meta$StatementHandle.toProto(Meta.java:1236)
at
org.apache.calcite.avatica.remote.Service$PrepareResponse.serialize(Service.java:1310)
at
org.apache.calcite.avatica.remote.Service$PrepareResponse.serialize(Service.java:1275)
at
org.apache.calcite.avatica.remote.ProtobufTranslationImpl.serializeResponse(ProtobufTranslationImpl.java:348)
at
org.apache.calcite.avatica.remote.ProtobufHandler.encode(ProtobufHandler.java:57)
at
org.apache.calcite.avatica.remote.ProtobufHandler.encode(ProtobufHandler.java:31)
at
org.apache.calcite.avatica.remote.AbstractHandler.apply(AbstractHandler.java:95)
at
org.apache.calcite.avatica.remote.ProtobufHandler.apply(ProtobufHandler.java:46)
at
org.apache.calcite.avatica.server.AvaticaProtobufHandler.handle(AvaticaProtobufHandler.java:127)
at
org.eclipse.jetty.server.handler.HandlerList.handle(HandlerList.java:52)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
at org.eclipse.jetty.server.Server.handle(Server.java:499)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:311)
at
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
at
org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:544)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
at java.lang.Thread.run(Thread.java:748)
{code}
was (Author: ptrbojko):
I am not judging where the problem is placed :) It is even possible that I've
connecting calcite and avatica wrong (although I am using examples from
avatica-server tests and examples and passing calcite like url to the database
in meta)
I've debug the whole test and internally avatica throws NPE as follows - it
doesn't catch it nor log it nowhere to be found easily :(
{code}
java.lang.NullPointerException
at
org.apache.calcite.avatica.proto.Common$AvaticaParameter$Builder.setClassName(Common.java:9040)
at
org.apache.calcite.avatica.AvaticaParameter.toProto(AvaticaParameter.java:64)
at org.apache.calcite.avatica.Meta$Signature.toProto(Meta.java:835)
at
org.apache.calcite.avatica.Meta$StatementHandle.toProto(Meta.java:1236)
at
org.apache.calcite.avatica.remote.Service$PrepareResponse.serialize(Service.java:1310)
at
org.apache.calcite.avatica.remote.Service$PrepareResponse.serialize(Service.java:1275)
at
org.apache.calcite.avatica.remote.ProtobufTranslationImpl.serializeResponse(ProtobufTranslationImpl.java:348)
at
org.apache.calcite.avatica.remote.ProtobufHandler.encode(ProtobufHandler.java:57)
at
org.apache.calcite.avatica.remote.ProtobufHandler.encode(ProtobufHandler.java:31)
at
org.apache.calcite.avatica.remote.AbstractHandler.apply(AbstractHandler.java:95)
at
org.apache.calcite.avatica.remote.ProtobufHandler.apply(ProtobufHandler.java:46)
at
org.apache.calcite.avatica.server.AvaticaProtobufHandler.handle(AvaticaProtobufHandler.java:127)
at
org.eclipse.jetty.server.handler.HandlerList.handle(HandlerList.java:52)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
at org.eclipse.jetty.server.Server.handle(Server.java:499)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:311)
at
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
at
org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:544)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
at java.lang.Thread.run(Thread.java:748)
{code}
> NPE when Avatica used as JDBC transport for Calcite and dynamic
[jira] [Comment Edited] (CALCITE-2613) NPE when Avatica used as JDBC transport for Calcite and dynamic param ? used
[
https://issues.apache.org/jira/browse/CALCITE-2613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16639919#comment-16639919
]
Piotr Bojko edited comment on CALCITE-2613 at 10/5/18 3:00 PM:
---
I am not judging where the problem is placed :) It is even possible that I am
connecting calcite and avatica wrong (although I am using examples from
avatica-server tests and passing calcite like url to the database in meta)
I've debug the whole test and internally avatica throws NPE as follows - it is
not catched nor logged it nowhere to be found easily :(
{code}
java.lang.NullPointerException
at
org.apache.calcite.avatica.proto.Common$AvaticaParameter$Builder.setClassName(Common.java:9040)
at
org.apache.calcite.avatica.AvaticaParameter.toProto(AvaticaParameter.java:64)
at org.apache.calcite.avatica.Meta$Signature.toProto(Meta.java:835)
at
org.apache.calcite.avatica.Meta$StatementHandle.toProto(Meta.java:1236)
at
org.apache.calcite.avatica.remote.Service$PrepareResponse.serialize(Service.java:1310)
at
org.apache.calcite.avatica.remote.Service$PrepareResponse.serialize(Service.java:1275)
at
org.apache.calcite.avatica.remote.ProtobufTranslationImpl.serializeResponse(ProtobufTranslationImpl.java:348)
at
org.apache.calcite.avatica.remote.ProtobufHandler.encode(ProtobufHandler.java:57)
at
org.apache.calcite.avatica.remote.ProtobufHandler.encode(ProtobufHandler.java:31)
at
org.apache.calcite.avatica.remote.AbstractHandler.apply(AbstractHandler.java:95)
at
org.apache.calcite.avatica.remote.ProtobufHandler.apply(ProtobufHandler.java:46)
at
org.apache.calcite.avatica.server.AvaticaProtobufHandler.handle(AvaticaProtobufHandler.java:127)
at
org.eclipse.jetty.server.handler.HandlerList.handle(HandlerList.java:52)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
at org.eclipse.jetty.server.Server.handle(Server.java:499)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:311)
at
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
at
org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:544)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
at java.lang.Thread.run(Thread.java:748)
{code}
was (Author: ptrbojko):
I am not judging where the problem is placed :) It is even possible that I am
connecting calcite and avatica wrong (although I am using examples from
avatica-server tests and passing calcite like url to the database in meta)
I've debug the whole test and internally avatica throws NPE as follows - it
doesn't catch it nor log it nowhere to be found easily :(
{code}
java.lang.NullPointerException
at
org.apache.calcite.avatica.proto.Common$AvaticaParameter$Builder.setClassName(Common.java:9040)
at
org.apache.calcite.avatica.AvaticaParameter.toProto(AvaticaParameter.java:64)
at org.apache.calcite.avatica.Meta$Signature.toProto(Meta.java:835)
at
org.apache.calcite.avatica.Meta$StatementHandle.toProto(Meta.java:1236)
at
org.apache.calcite.avatica.remote.Service$PrepareResponse.serialize(Service.java:1310)
at
org.apache.calcite.avatica.remote.Service$PrepareResponse.serialize(Service.java:1275)
at
org.apache.calcite.avatica.remote.ProtobufTranslationImpl.serializeResponse(ProtobufTranslationImpl.java:348)
at
org.apache.calcite.avatica.remote.ProtobufHandler.encode(ProtobufHandler.java:57)
at
org.apache.calcite.avatica.remote.ProtobufHandler.encode(ProtobufHandler.java:31)
at
org.apache.calcite.avatica.remote.AbstractHandler.apply(AbstractHandler.java:95)
at
org.apache.calcite.avatica.remote.ProtobufHandler.apply(ProtobufHandler.java:46)
at
org.apache.calcite.avatica.server.AvaticaProtobufHandler.handle(AvaticaProtobufHandler.java:127)
at
org.eclipse.jetty.server.handler.HandlerList.handle(HandlerList.java:52)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
at org.eclipse.jetty.server.Server.handle(Server.java:499)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:311)
at
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
at
org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:544)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
at java.lang.Thread.run(Thread.java:748)
{code}
> NPE when Avatica used as JDBC transport for Calcite and dynamic param ? used
[jira] [Comment Edited] (CALCITE-2613) NPE when Avatica used as JDBC transport for Calcite and dynamic param ? used
[
https://issues.apache.org/jira/browse/CALCITE-2613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16639919#comment-16639919
]
Piotr Bojko edited comment on CALCITE-2613 at 10/5/18 2:59 PM:
---
I am not judging where the problem is placed :) It is even possible that I am
connecting calcite and avatica wrong (although I am using examples from
avatica-server tests and passing calcite like url to the database in meta)
I've debug the whole test and internally avatica throws NPE as follows - it
doesn't catch it nor log it nowhere to be found easily :(
{code}
java.lang.NullPointerException
at
org.apache.calcite.avatica.proto.Common$AvaticaParameter$Builder.setClassName(Common.java:9040)
at
org.apache.calcite.avatica.AvaticaParameter.toProto(AvaticaParameter.java:64)
at org.apache.calcite.avatica.Meta$Signature.toProto(Meta.java:835)
at
org.apache.calcite.avatica.Meta$StatementHandle.toProto(Meta.java:1236)
at
org.apache.calcite.avatica.remote.Service$PrepareResponse.serialize(Service.java:1310)
at
org.apache.calcite.avatica.remote.Service$PrepareResponse.serialize(Service.java:1275)
at
org.apache.calcite.avatica.remote.ProtobufTranslationImpl.serializeResponse(ProtobufTranslationImpl.java:348)
at
org.apache.calcite.avatica.remote.ProtobufHandler.encode(ProtobufHandler.java:57)
at
org.apache.calcite.avatica.remote.ProtobufHandler.encode(ProtobufHandler.java:31)
at
org.apache.calcite.avatica.remote.AbstractHandler.apply(AbstractHandler.java:95)
at
org.apache.calcite.avatica.remote.ProtobufHandler.apply(ProtobufHandler.java:46)
at
org.apache.calcite.avatica.server.AvaticaProtobufHandler.handle(AvaticaProtobufHandler.java:127)
at
org.eclipse.jetty.server.handler.HandlerList.handle(HandlerList.java:52)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
at org.eclipse.jetty.server.Server.handle(Server.java:499)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:311)
at
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
at
org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:544)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
at java.lang.Thread.run(Thread.java:748)
{code}
was (Author: ptrbojko):
I am not judging where the problem is placed :) It is even possible that I've
connecting calcite and avatica wrong (although I am using examples from
avatica-server tests and passing calcite like url to the database in meta)
I've debug the whole test and internally avatica throws NPE as follows - it
doesn't catch it nor log it nowhere to be found easily :(
{code}
java.lang.NullPointerException
at
org.apache.calcite.avatica.proto.Common$AvaticaParameter$Builder.setClassName(Common.java:9040)
at
org.apache.calcite.avatica.AvaticaParameter.toProto(AvaticaParameter.java:64)
at org.apache.calcite.avatica.Meta$Signature.toProto(Meta.java:835)
at
org.apache.calcite.avatica.Meta$StatementHandle.toProto(Meta.java:1236)
at
org.apache.calcite.avatica.remote.Service$PrepareResponse.serialize(Service.java:1310)
at
org.apache.calcite.avatica.remote.Service$PrepareResponse.serialize(Service.java:1275)
at
org.apache.calcite.avatica.remote.ProtobufTranslationImpl.serializeResponse(ProtobufTranslationImpl.java:348)
at
org.apache.calcite.avatica.remote.ProtobufHandler.encode(ProtobufHandler.java:57)
at
org.apache.calcite.avatica.remote.ProtobufHandler.encode(ProtobufHandler.java:31)
at
org.apache.calcite.avatica.remote.AbstractHandler.apply(AbstractHandler.java:95)
at
org.apache.calcite.avatica.remote.ProtobufHandler.apply(ProtobufHandler.java:46)
at
org.apache.calcite.avatica.server.AvaticaProtobufHandler.handle(AvaticaProtobufHandler.java:127)
at
org.eclipse.jetty.server.handler.HandlerList.handle(HandlerList.java:52)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
at org.eclipse.jetty.server.Server.handle(Server.java:499)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:311)
at
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
at
org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:544)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
at java.lang.Thread.run(Thread.java:748)
{code}
> NPE when Avatica used as JDBC transport for Calcite and dynamic param ? used
[jira] [Commented] (CALCITE-2613) NPE when Avatica used as JDBC transport for Calcite and dynamic param ? used
[
https://issues.apache.org/jira/browse/CALCITE-2613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16639919#comment-16639919
]
Piotr Bojko commented on CALCITE-2613:
--
I am not judging where the problem is placed :) It is even possible that I've
connecting calcite and avatica wrong (although I am using examples from
avatica-server tests and examples and passing calcite like url to the database
in meta)
I've debug the whole test and internally avatica throws NPE as follows - it
doesn't catch it nor log it nowhere to be found easily :(
{code}
java.lang.NullPointerException
at
org.apache.calcite.avatica.proto.Common$AvaticaParameter$Builder.setClassName(Common.java:9040)
at
org.apache.calcite.avatica.AvaticaParameter.toProto(AvaticaParameter.java:64)
at org.apache.calcite.avatica.Meta$Signature.toProto(Meta.java:835)
at
org.apache.calcite.avatica.Meta$StatementHandle.toProto(Meta.java:1236)
at
org.apache.calcite.avatica.remote.Service$PrepareResponse.serialize(Service.java:1310)
at
org.apache.calcite.avatica.remote.Service$PrepareResponse.serialize(Service.java:1275)
at
org.apache.calcite.avatica.remote.ProtobufTranslationImpl.serializeResponse(ProtobufTranslationImpl.java:348)
at
org.apache.calcite.avatica.remote.ProtobufHandler.encode(ProtobufHandler.java:57)
at
org.apache.calcite.avatica.remote.ProtobufHandler.encode(ProtobufHandler.java:31)
at
org.apache.calcite.avatica.remote.AbstractHandler.apply(AbstractHandler.java:95)
at
org.apache.calcite.avatica.remote.ProtobufHandler.apply(ProtobufHandler.java:46)
at
org.apache.calcite.avatica.server.AvaticaProtobufHandler.handle(AvaticaProtobufHandler.java:127)
at
org.eclipse.jetty.server.handler.HandlerList.handle(HandlerList.java:52)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
at org.eclipse.jetty.server.Server.handle(Server.java:499)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:311)
at
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
at
org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:544)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
at java.lang.Thread.run(Thread.java:748)
{code}
> NPE when Avatica used as JDBC transport for Calcite and dynamic param ? used
> --
>
> Key: CALCITE-2613
> URL: https://issues.apache.org/jira/browse/CALCITE-2613
> Project: Calcite
> Issue Type: Bug
> Components: avatica, core
>Affects Versions: 1.17.0, avatica-1.12.0, 1.18.0
>Reporter: Piotr Bojko
>Priority: Major
>
> This is a follow from dev@apache forum discussion. When avatica is wrapping
> through JdbcMeta a calcite connection and prepared statement contains dynamic
> parameters, then AvaticaParameters.toProto throws NPE (underlying Builder of
> Common.AvaticaParameter to be exact).
> FYI [~elserj]
> I will attach a test case to this issue in a sec.
> {quote}
> An AvaticaParameter with a null classname sounds wrong to me. We should
> know the type (per the schema) for some variable, regardless of whether
> or not it is nullable.
> If you can put together a unit test showing what you're seeing in
> Avatica, that would go an extremely long way. It may also just be
> something Calcite is doing which should be corrected (so, a unit test
> there would be a starting point, too).
> Feel free to ping me on Jira. Thanks Piotr!
> On 10/4/18 9:08 AM, ptr.bo...@gmail.com wrote:
> > I've logged a JIRA for the first bug, with a fix proposal -
> > https://issues.apache.org/jira/browse/CALCITE-2609.
> >
> > But the case with AvaticaParameter NPE still remains unclear for me - in
> > terms of design. Help needed :)
> >
> > On Wed, Oct 3, 2018 at 4:14 PM ptr.bo...@gmail.com
> > wrote:
> >
> >> As for the nulls in AvaticaParameter class - I believe this is how calcite
> >> works. For example for the following query *"select * from filters where
> >> name = ?"* - despite the definition of filters table - Calcite will
> >> create org.apache.calcite.avatica.AvaticaParameter with nullable className.
> >>
> >> My case with more details is following: based on calcite-avatica/sever
> >> I've created a mini jdbc server (servlet) exposing Calcite connection with
> >> my custom schemas. I would like to expose my domain as an SQL database so
> >> with Calcite as an engine and domain translation and Avatica as a JDBC
> >> implementor the resulting implementation is very elegant and works great.
> >>
> >> However the same query *"select * from
[jira] [Commented] (CALCITE-2613) NPE when Avatica used as JDBC transport for Calcite and dynamic param ? used
[
https://issues.apache.org/jira/browse/CALCITE-2613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16639804#comment-16639804
]
Piotr Bojko commented on CALCITE-2613:
--
Note that even this bug is resolved - the second one CALCITE-2609 can still
occur.
> NPE when Avatica used as JDBC transport for Calcite and dynamic param ? used
> --
>
> Key: CALCITE-2613
> URL: https://issues.apache.org/jira/browse/CALCITE-2613
> Project: Calcite
> Issue Type: Bug
> Components: avatica, core
>Affects Versions: 1.17.0, avatica-1.12.0, 1.18.0
>Reporter: Piotr Bojko
>Priority: Major
>
> This is a follow from dev@apache forum discussion. When avatica is wrapping
> through JdbcMeta a calcite connection and prepared statement contains dynamic
> parameters, then AvaticaParameters.toProto throws NPE (underlying Builder of
> Common.AvaticaParameter to be exact).
> FYI [~elserj]
> I will attach a test case to this issue in a sec.
> {quote}
> An AvaticaParameter with a null classname sounds wrong to me. We should
> know the type (per the schema) for some variable, regardless of whether
> or not it is nullable.
> If you can put together a unit test showing what you're seeing in
> Avatica, that would go an extremely long way. It may also just be
> something Calcite is doing which should be corrected (so, a unit test
> there would be a starting point, too).
> Feel free to ping me on Jira. Thanks Piotr!
> On 10/4/18 9:08 AM, ptr.bo...@gmail.com wrote:
> > I've logged a JIRA for the first bug, with a fix proposal -
> > https://issues.apache.org/jira/browse/CALCITE-2609.
> >
> > But the case with AvaticaParameter NPE still remains unclear for me - in
> > terms of design. Help needed :)
> >
> > On Wed, Oct 3, 2018 at 4:14 PM ptr.bo...@gmail.com
> > wrote:
> >
> >> As for the nulls in AvaticaParameter class - I believe this is how calcite
> >> works. For example for the following query *"select * from filters where
> >> name = ?"* - despite the definition of filters table - Calcite will
> >> create org.apache.calcite.avatica.AvaticaParameter with nullable className.
> >>
> >> My case with more details is following: based on calcite-avatica/sever
> >> I've created a mini jdbc server (servlet) exposing Calcite connection with
> >> my custom schemas. I would like to expose my domain as an SQL database so
> >> with Calcite as an engine and domain translation and Avatica as a JDBC
> >> implementor the resulting implementation is very elegant and works great.
> >>
> >> However the same query *"select * from filters where name = ?" *run
> >> through avatica jdbc implementation is resulting NPE
> >> in Common.AvaticaParameter AvaticaParameter.toProto().
> >>
> >> On Wed, Oct 3, 2018 at 12:46 AM Josh Elser wrote:
> >>
> >>> re: nulls on className, that's how Protobuf itself works. You can't set
> >>> null for an attribute.
> >>>
> >>> What is the circumstance where you would have a null className on an
> >>> AvaticaParameter?
> >>>
> >>> We could proactively check in the constructor to AvaticaParameter that
> >>> you don't provide null arguments, but that could be argued in either
> >>> direction (e.g. you should not provide null arguments in the first place).
> >>>
> >>> On 10/2/18 5:11 PM, ptr.bo...@gmail.com wrote:
> Hello,
>
> It seems that my case consists of two bugs:
>
> First one is similar to what I've already patched twice - Calcite pushes
> too much to underlying jdbc schema, in this case "?" operator. Resulting
> subquery onto jdbc schema ends with error about it (? not resolved).
> >>> This
> one belongs to Calcite.
>
> The second one is located
> at org.apache.calcite.avatica.AvaticaParameter.toProto method.
> AvaticaParameter can be a live nullable className but
> Common.AvaticaParameter does not allow to set nulls on className.
> >>> toProto
> method - please verify me - should be more carefull about it and not set
> className on a builder when it is null. This one belongs to Avatica.
>
> If anyone has time to check me it would be great. I will log then each
> >>> bug
> to appropriate apache project in Jira. I should patch first one fairly
> >>> easy.
>
> Regards,
> Piotr
>
> On Mon, Oct 1, 2018 at 1:50 PM Francis Chuang
> wrote:
>
> > Hey Piotr,
> >
> > Thanks for reporting this! I am not familiar with Avatica's internals,
> > so can't recommend how this can be fixed. However, I would suggest
> > writing a test case to reproduce the problem in the meantime.
> >
> > Francis
> >
> > On 1/10/2018 8:59 PM, ptr.bo...@gmail.com wrote:
> >> Hello fellow calcite dev team :)
> >>
> >> I have discovered the case
[jira] [Commented] (CALCITE-2613) NPE when Avatica used as JDBC transport for Calcite and dynamic param ? used
[
https://issues.apache.org/jira/browse/CALCITE-2613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16639796#comment-16639796
]
Piotr Bojko commented on CALCITE-2613:
--
[Branch with a test
case|https://github.com/ptrbojko/calcite/tree/bug/CALCITE-2613]
> NPE when Avatica used as JDBC transport for Calcite and dynamic param ? used
> --
>
> Key: CALCITE-2613
> URL: https://issues.apache.org/jira/browse/CALCITE-2613
> Project: Calcite
> Issue Type: Bug
> Components: avatica, core
>Affects Versions: 1.17.0, avatica-1.12.0, 1.18.0
>Reporter: Piotr Bojko
>Priority: Major
>
> This is a follow from dev@apache forum discussion. When avatica is wrapping
> through JdbcMeta a calcite connection and prepared statement contains dynamic
> parameters, then AvaticaParameters.toProto throws NPE (underlying Builder of
> Common.AvaticaParameter to be exact).
> FYI [~elserj]
> I will attach a test case to this issue in a sec.
> {quote}
> An AvaticaParameter with a null classname sounds wrong to me. We should
> know the type (per the schema) for some variable, regardless of whether
> or not it is nullable.
> If you can put together a unit test showing what you're seeing in
> Avatica, that would go an extremely long way. It may also just be
> something Calcite is doing which should be corrected (so, a unit test
> there would be a starting point, too).
> Feel free to ping me on Jira. Thanks Piotr!
> On 10/4/18 9:08 AM, ptr.bo...@gmail.com wrote:
> > I've logged a JIRA for the first bug, with a fix proposal -
> > https://issues.apache.org/jira/browse/CALCITE-2609.
> >
> > But the case with AvaticaParameter NPE still remains unclear for me - in
> > terms of design. Help needed :)
> >
> > On Wed, Oct 3, 2018 at 4:14 PM ptr.bo...@gmail.com
> > wrote:
> >
> >> As for the nulls in AvaticaParameter class - I believe this is how calcite
> >> works. For example for the following query *"select * from filters where
> >> name = ?"* - despite the definition of filters table - Calcite will
> >> create org.apache.calcite.avatica.AvaticaParameter with nullable className.
> >>
> >> My case with more details is following: based on calcite-avatica/sever
> >> I've created a mini jdbc server (servlet) exposing Calcite connection with
> >> my custom schemas. I would like to expose my domain as an SQL database so
> >> with Calcite as an engine and domain translation and Avatica as a JDBC
> >> implementor the resulting implementation is very elegant and works great.
> >>
> >> However the same query *"select * from filters where name = ?" *run
> >> through avatica jdbc implementation is resulting NPE
> >> in Common.AvaticaParameter AvaticaParameter.toProto().
> >>
> >> On Wed, Oct 3, 2018 at 12:46 AM Josh Elser wrote:
> >>
> >>> re: nulls on className, that's how Protobuf itself works. You can't set
> >>> null for an attribute.
> >>>
> >>> What is the circumstance where you would have a null className on an
> >>> AvaticaParameter?
> >>>
> >>> We could proactively check in the constructor to AvaticaParameter that
> >>> you don't provide null arguments, but that could be argued in either
> >>> direction (e.g. you should not provide null arguments in the first place).
> >>>
> >>> On 10/2/18 5:11 PM, ptr.bo...@gmail.com wrote:
> Hello,
>
> It seems that my case consists of two bugs:
>
> First one is similar to what I've already patched twice - Calcite pushes
> too much to underlying jdbc schema, in this case "?" operator. Resulting
> subquery onto jdbc schema ends with error about it (? not resolved).
> >>> This
> one belongs to Calcite.
>
> The second one is located
> at org.apache.calcite.avatica.AvaticaParameter.toProto method.
> AvaticaParameter can be a live nullable className but
> Common.AvaticaParameter does not allow to set nulls on className.
> >>> toProto
> method - please verify me - should be more carefull about it and not set
> className on a builder when it is null. This one belongs to Avatica.
>
> If anyone has time to check me it would be great. I will log then each
> >>> bug
> to appropriate apache project in Jira. I should patch first one fairly
> >>> easy.
>
> Regards,
> Piotr
>
> On Mon, Oct 1, 2018 at 1:50 PM Francis Chuang
> wrote:
>
> > Hey Piotr,
> >
> > Thanks for reporting this! I am not familiar with Avatica's internals,
> > so can't recommend how this can be fixed. However, I would suggest
> > writing a test case to reproduce the problem in the meantime.
> >
> > Francis
> >
> > On 1/10/2018 8:59 PM, ptr.bo...@gmail.com wrote:
> >> Hello fellow calcite dev team :)
> >>
> >> I have discovered the case
[jira] [Created] (CALCITE-2613) NPE when Avatica used as JDBC transport for Calcite and dynamic param ? used
Piotr Bojko created CALCITE-2613:
Summary: NPE when Avatica used as JDBC transport for Calcite and
dynamic param ? used
Key: CALCITE-2613
URL: https://issues.apache.org/jira/browse/CALCITE-2613
Project: Calcite
Issue Type: Bug
Components: avatica, core
Affects Versions: avatica-1.12.0, 1.17.0, 1.18.0
Reporter: Piotr Bojko
This is a follow from dev@apache forum discussion. When avatica is wrapping
through JdbcMeta a calcite connection and prepared statement contains dynamic
parameters, then AvaticaParameters.toProto throws NPE (underlying Builder of
Common.AvaticaParameter to be exact).
FYI [~elserj]
I will attach a test case to this issue in a sec.
{quote}
An AvaticaParameter with a null classname sounds wrong to me. We should
know the type (per the schema) for some variable, regardless of whether
or not it is nullable.
If you can put together a unit test showing what you're seeing in
Avatica, that would go an extremely long way. It may also just be
something Calcite is doing which should be corrected (so, a unit test
there would be a starting point, too).
Feel free to ping me on Jira. Thanks Piotr!
On 10/4/18 9:08 AM, ptr.bo...@gmail.com wrote:
> I've logged a JIRA for the first bug, with a fix proposal -
> https://issues.apache.org/jira/browse/CALCITE-2609.
>
> But the case with AvaticaParameter NPE still remains unclear for me - in
> terms of design. Help needed :)
>
> On Wed, Oct 3, 2018 at 4:14 PM ptr.bo...@gmail.com
> wrote:
>
>> As for the nulls in AvaticaParameter class - I believe this is how calcite
>> works. For example for the following query *"select * from filters where
>> name = ?"* - despite the definition of filters table - Calcite will
>> create org.apache.calcite.avatica.AvaticaParameter with nullable className.
>>
>> My case with more details is following: based on calcite-avatica/sever
>> I've created a mini jdbc server (servlet) exposing Calcite connection with
>> my custom schemas. I would like to expose my domain as an SQL database so
>> with Calcite as an engine and domain translation and Avatica as a JDBC
>> implementor the resulting implementation is very elegant and works great.
>>
>> However the same query *"select * from filters where name = ?" *run
>> through avatica jdbc implementation is resulting NPE
>> in Common.AvaticaParameter AvaticaParameter.toProto().
>>
>> On Wed, Oct 3, 2018 at 12:46 AM Josh Elser wrote:
>>
>>> re: nulls on className, that's how Protobuf itself works. You can't set
>>> null for an attribute.
>>>
>>> What is the circumstance where you would have a null className on an
>>> AvaticaParameter?
>>>
>>> We could proactively check in the constructor to AvaticaParameter that
>>> you don't provide null arguments, but that could be argued in either
>>> direction (e.g. you should not provide null arguments in the first place).
>>>
>>> On 10/2/18 5:11 PM, ptr.bo...@gmail.com wrote:
Hello,
It seems that my case consists of two bugs:
First one is similar to what I've already patched twice - Calcite pushes
too much to underlying jdbc schema, in this case "?" operator. Resulting
subquery onto jdbc schema ends with error about it (? not resolved).
>>> This
one belongs to Calcite.
The second one is located
at org.apache.calcite.avatica.AvaticaParameter.toProto method.
AvaticaParameter can be a live nullable className but
Common.AvaticaParameter does not allow to set nulls on className.
>>> toProto
method - please verify me - should be more carefull about it and not set
className on a builder when it is null. This one belongs to Avatica.
If anyone has time to check me it would be great. I will log then each
>>> bug
to appropriate apache project in Jira. I should patch first one fairly
>>> easy.
Regards,
Piotr
On Mon, Oct 1, 2018 at 1:50 PM Francis Chuang >>>
wrote:
> Hey Piotr,
>
> Thanks for reporting this! I am not familiar with Avatica's internals,
> so can't recommend how this can be fixed. However, I would suggest
> writing a test case to reproduce the problem in the meantime.
>
> Francis
>
> On 1/10/2018 8:59 PM, ptr.bo...@gmail.com wrote:
>> Hello fellow calcite dev team :)
>>
>> I have discovered the case with NPE when trying to use parameters on
>> prepared statement:
>> java.lang.NullPointerException
>> at
>>
>
>>> org.apache.calcite.avatica.proto.Common$AvaticaParameter$Builder.setClassName(Common.java:9040)
>> at
>>
>
>>> org.apache.calcite.avatica.AvaticaParameter.toProto(AvaticaParameter.java:64)
>> at org.apache.calcite.avatica.Meta$Signature.toProto(Meta.java:835)
>> at
> org.apache.calcite.avatica.Meta$StatementHandle.toProto(Meta.java:1236)
>> at
>>
>
>>>
[jira] [Commented] (CALCITE-2609) Dynamic parameters ? pushed to underlying jdbc schema
[ https://issues.apache.org/jira/browse/CALCITE-2609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16638280#comment-16638280 ] Piotr Bojko commented on CALCITE-2609: -- There is JdbcTest.testUpdateBind which is failing but I have doubts whether it is properly designed test. It relays on assumption that UPDATE clause is implemented on planner level, whethe I think it is not. Test worked before my patch probably because the whole query was pushed to jdbc underlying subschemam which was the main cause of this ticket. > Dynamic parameters ? pushed to underlying jdbc schema > - > > Key: CALCITE-2609 > URL: https://issues.apache.org/jira/browse/CALCITE-2609 > Project: Calcite > Issue Type: Bug >Affects Versions: 1.17.0, 1.18.0 >Reporter: Piotr Bojko >Assignee: Julian Hyde >Priority: Major > > When using PreparedStatement parameters "?" they can be pushed down to jdbc > subschemas which cause an error. > RexDynamicParam should no be pushed to jdbc schema. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2609) Dynamic parameters ? pushed to underlying jdbc schema
[ https://issues.apache.org/jira/browse/CALCITE-2609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16638216#comment-16638216 ] Piotr Bojko commented on CALCITE-2609: -- I've added a proposal of a fix. But have one existing test failing and I'v trying to find why. Please check the proposal and test cases and decide if a fix follows good directions. > Dynamic parameters ? pushed to underlying jdbc schema > - > > Key: CALCITE-2609 > URL: https://issues.apache.org/jira/browse/CALCITE-2609 > Project: Calcite > Issue Type: Bug >Affects Versions: 1.17.0, 1.18.0 >Reporter: Piotr Bojko >Assignee: Julian Hyde >Priority: Major > > When using PreparedStatement parameters "?" they can be pushed down to jdbc > subschemas which cause an error. > RexDynamicParam should no be pushed to jdbc schema. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2609) Dynamic parameters ? pushed to underlying jdbc schema
[ https://issues.apache.org/jira/browse/CALCITE-2609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16638188#comment-16638188 ] Piotr Bojko commented on CALCITE-2609: -- I've added a test case straight in core. I am looking for a patch around JdbcRules (filtering the filter rule when DynamicParam in condition exists) now. > Dynamic parameters ? pushed to underlying jdbc schema > - > > Key: CALCITE-2609 > URL: https://issues.apache.org/jira/browse/CALCITE-2609 > Project: Calcite > Issue Type: Bug >Affects Versions: 1.17.0, 1.18.0 >Reporter: Piotr Bojko >Assignee: Julian Hyde >Priority: Major > > When using PreparedStatement parameters "?" they can be pushed down to jdbc > subschemas which cause an error. > RexDynamicParam should no be pushed to jdbc schema. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2609) Dynamic parameters ? pushed to underlying jdbc schema
[ https://issues.apache.org/jira/browse/CALCITE-2609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16638003#comment-16638003 ] Piotr Bojko commented on CALCITE-2609: -- Here is a reproduction - https://github.com/ptrbojko/calcite/tree/bug/CALCITE-2609 > Dynamic parameters ? pushed to underlying jdbc schema > - > > Key: CALCITE-2609 > URL: https://issues.apache.org/jira/browse/CALCITE-2609 > Project: Calcite > Issue Type: Bug >Affects Versions: 1.17.0, 1.18.0 >Reporter: Piotr Bojko >Assignee: Julian Hyde >Priority: Major > > When using PreparedStatement parameters "?" they can be pushed down to jdbc > subschemas which cause an error. > RexDynamicParam should no be pushed to jdbc schema. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-2609) Dynamic parameters ? pushed to underlying jdbc schema
Piotr Bojko created CALCITE-2609: Summary: Dynamic parameters ? pushed to underlying jdbc schema Key: CALCITE-2609 URL: https://issues.apache.org/jira/browse/CALCITE-2609 Project: Calcite Issue Type: Bug Affects Versions: 1.17.0, 1.18.0 Reporter: Piotr Bojko Assignee: Julian Hyde When using PreparedStatement parameters "?" they can be pushed down to jdbc subschemas which cause an error. RexDynamicParam should no be pushed to jdbc schema. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2511) Possible bug in parsing implementation of rown_num select
[
https://issues.apache.org/jira/browse/CALCITE-2511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16636780#comment-16636780
]
Piotr Bojko commented on CALCITE-2511:
--
[~vladimirsitnikov] it works now! Thank you.
This issue can be closed.
> Possible bug in parsing implementation of rown_num select
> -
>
> Key: CALCITE-2511
> URL: https://issues.apache.org/jira/browse/CALCITE-2511
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: Piotr Bojko
>Assignee: Julian Hyde
>Priority: Major
> Attachments: implementation.java
>
>
> I've found a possible bug.
> With following view:
> {code:json}
> {
> "name": "STEPS",
> "type": "view",
> "sql": [
> "WITH ALLROWS AS ( ",
> " SELECT ",
> " ROW_NUMBER() OVER W AS IDX, I.ID ISSUE, COALESCE(CG.AUTHOR,
> I.REPORTER) AS AUTHOR, COALESCE(CI.OLDVALUE, I.STATUS) AS STATUS, I.CREATED
> AS STARTDATE, CG.CREATED AS ENDDATE ",
> " FROM ISSUES AS I ",
> " JOIN INTERNAL.CHANGEGROUP AS CG ON CG.ISSUEID = I.ID ",
> " JOIN INTERNAL.CHANGEITEM AS CI ON CI.GROUPID = CG.ID ",
> " WHERE CI.FIELDTYPE = 'jira' AND CI.FIELD = 'status' ",
> " WINDOW w AS (PARTITION BY i.id ORDER BY CG.CREATED) ",
> ") ",
> "SELECT ISSUE, AUTHOR, STATUS, STARTDATE, ENDDATE ",
> "FROM ALLROWS WHERE ALLROWS.IDX <= 1 ",
> "UNION ALL ",
> "SELECT I.ID AS ISSUE, CG.AUTHOR, CI.NEWVALUE AS STATUS,
> CG.CREATED AS STARTDATE, LEAD(CG.CREATED, 1) OVER W AS ENDDATE ",
> "FROM ISSUES i ",
> "JOIN INTERNAL.CHANGEGROUP AS CG ON CG.ISSUEID = I.ID ",
> "JOIN INTERNAL.CHANGEITEM AS CI ON CI.GROUPID = CG.ID ",
> "WHERE CI.FIELDTYPE = 'jira' AND CI.FIELD = 'status' ",
> "WINDOW W AS (PARTITION BY I.ID ORDER BY CG.CREATED) "
> ]
> },
> {code}
> When performig
> {code:sql}
> SELECT * FROM STEPS
> {code}
> The result is
> {noformat}
> Line 1556, Column 0: Java$AmbiguousName is not allowed as an expression
> statement. Expressions statements must be one of assignments, method
> invocations, or object allocations..
> {noformat}
> As an attachment, I've attached implementation. Clearly the line 1555/1556 is
> wrong...
> I've discovered then, when removing *WHERE ALLROWS.IDX <= 1* - all is ok.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2511) Possible bug in parsing implementation of rown_num select
[
https://issues.apache.org/jira/browse/CALCITE-2511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16636613#comment-16636613
]
Piotr Bojko commented on CALCITE-2511:
--
I will check this.
> Possible bug in parsing implementation of rown_num select
> -
>
> Key: CALCITE-2511
> URL: https://issues.apache.org/jira/browse/CALCITE-2511
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: Piotr Bojko
>Assignee: Julian Hyde
>Priority: Major
> Attachments: implementation.java
>
>
> I've found a possible bug.
> With following view:
> {code:json}
> {
> "name": "STEPS",
> "type": "view",
> "sql": [
> "WITH ALLROWS AS ( ",
> " SELECT ",
> " ROW_NUMBER() OVER W AS IDX, I.ID ISSUE, COALESCE(CG.AUTHOR,
> I.REPORTER) AS AUTHOR, COALESCE(CI.OLDVALUE, I.STATUS) AS STATUS, I.CREATED
> AS STARTDATE, CG.CREATED AS ENDDATE ",
> " FROM ISSUES AS I ",
> " JOIN INTERNAL.CHANGEGROUP AS CG ON CG.ISSUEID = I.ID ",
> " JOIN INTERNAL.CHANGEITEM AS CI ON CI.GROUPID = CG.ID ",
> " WHERE CI.FIELDTYPE = 'jira' AND CI.FIELD = 'status' ",
> " WINDOW w AS (PARTITION BY i.id ORDER BY CG.CREATED) ",
> ") ",
> "SELECT ISSUE, AUTHOR, STATUS, STARTDATE, ENDDATE ",
> "FROM ALLROWS WHERE ALLROWS.IDX <= 1 ",
> "UNION ALL ",
> "SELECT I.ID AS ISSUE, CG.AUTHOR, CI.NEWVALUE AS STATUS,
> CG.CREATED AS STARTDATE, LEAD(CG.CREATED, 1) OVER W AS ENDDATE ",
> "FROM ISSUES i ",
> "JOIN INTERNAL.CHANGEGROUP AS CG ON CG.ISSUEID = I.ID ",
> "JOIN INTERNAL.CHANGEITEM AS CI ON CI.GROUPID = CG.ID ",
> "WHERE CI.FIELDTYPE = 'jira' AND CI.FIELD = 'status' ",
> "WINDOW W AS (PARTITION BY I.ID ORDER BY CG.CREATED) "
> ]
> },
> {code}
> When performig
> {code:sql}
> SELECT * FROM STEPS
> {code}
> The result is
> {noformat}
> Line 1556, Column 0: Java$AmbiguousName is not allowed as an expression
> statement. Expressions statements must be one of assignments, method
> invocations, or object allocations..
> {noformat}
> As an attachment, I've attached implementation. Clearly the line 1555/1556 is
> wrong...
> I've discovered then, when removing *WHERE ALLROWS.IDX <= 1* - all is ok.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2541) Calcite core is vulnerable to exposing through OSGI
[
https://issues.apache.org/jira/browse/CALCITE-2541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16606829#comment-16606829
]
Piotr Bojko commented on CALCITE-2541:
--
Having appropriate setup of two osgi bundles would require two maven project. I
thought about striping the problem only to class loaders setup which will
mimmick the osgi class loaders.
> Calcite core is vulnerable to exposing through OSGI
> ---
>
> Key: CALCITE-2541
> URL: https://issues.apache.org/jira/browse/CALCITE-2541
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: Piotr Bojko
>Assignee: Julian Hyde
>Priority: Major
>
> When exposing connection created by Calcite through OSGI to another bundle -
> class not found it thrown everywhere from code as following:
> {code:java}
> ICompilerFactory compilerFactory;
> try {
> compilerFactory = CompilerFactoryFactory.getDefaultCompilerFactory();
> } catch (Exception e) {
> throw new IllegalStateException(
> "Unable to instantiate java compiler", e);
> }
> {code}
> This is because org.codehaus.commons.compiler.CompilerFactoryFactory uses
> classloader from current thread, where in OSGI exposed to different bundles
> thread classloader may not reach valid janino or
> org.codehaus.commons.compiler, appropriate for Calcite version (or at all).
> I would suggest changing the mentioned code with additional fallback:
>
> {code:java}
> ICompilerFactory compilerFactory;
> try {
> compilerFactory = CompilerFactoryFactory.getDefaultCompilerFactory();
> } catch (ClassNotFoundException e) {
> compilerFactory = new org.codehaus.janino.CompilerFactory();
> } catch (Exception e) {
> throw new IllegalStateException(
> "Unable to instantiate java compiler", e);
> }
> {code}
> Change in:
> * EnumerableInterpretable.getBindable(ClassDeclaration, String, int)
> * JaninoRexCompiler.getScalar(ClassDeclaration, String)
> * JaninoRelMetadataProvider.compile(String, String, MetadataDef,
> List)
> This should clear the way between calcite and an osgi world :)
> When accepted I will make a pull request.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CALCITE-2541) Calcite core is vulnerable to exposing through OSGI
Piotr Bojko created CALCITE-2541:
Summary: Calcite core is vulnerable to exposing through OSGI
Key: CALCITE-2541
URL: https://issues.apache.org/jira/browse/CALCITE-2541
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.17.0
Reporter: Piotr Bojko
Assignee: Julian Hyde
When exposing connection created by Calcite through OSGI to another bundle -
class not found it thrown everywhere from code as following:
{code:java}
ICompilerFactory compilerFactory;
try {
compilerFactory = CompilerFactoryFactory.getDefaultCompilerFactory();
} catch (Exception e) {
throw new IllegalStateException(
"Unable to instantiate java compiler", e);
}
{code}
This is because org.codehaus.commons.compiler.CompilerFactoryFactory uses
classloader from current thread, where in OSGI exposed to different bundles
thread classloader may not reach valid janino or org.codehaus.commons.compiler,
appropriate for Calcite version (or at all).
I would suggest changing the mentioned code with additional fallback:
{code:java}
ICompilerFactory compilerFactory;
try {
compilerFactory = CompilerFactoryFactory.getDefaultCompilerFactory();
} catch (ClassNotFoundException e) {
compilerFactory = new org.codehaus.janino.CompilerFactory();
} catch (Exception e) {
throw new IllegalStateException(
"Unable to instantiate java compiler", e);
}
{code}
Change in:
* EnumerableInterpretable.getBindable(ClassDeclaration, String, int)
* JaninoRexCompiler.getScalar(ClassDeclaration, String)
* JaninoRelMetadataProvider.compile(String, String, MetadataDef,
List)
This should clear the way between calcite and an osgi world :)
When accepted I will make a pull request.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2511) Possible bug in parsing implementation of rown_num select
[
https://issues.apache.org/jira/browse/CALCITE-2511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16597349#comment-16597349
]
Piotr Bojko commented on CALCITE-2511:
--
I'm not sure how to reproduce this in calcite as test case for now - it is
simple beyond me :(
> Possible bug in parsing implementation of rown_num select
> -
>
> Key: CALCITE-2511
> URL: https://issues.apache.org/jira/browse/CALCITE-2511
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0, 1.18.0
>Reporter: Piotr Bojko
>Assignee: Julian Hyde
>Priority: Major
> Attachments: implementation.java
>
>
> I've found a possible bug.
> With following view:
> {code:json}
> {
> "name": "STEPS",
> "type": "view",
> "sql": [
> "WITH ALLROWS AS ( ",
> " SELECT ",
> " ROW_NUMBER() OVER W AS IDX, I.ID ISSUE, COALESCE(CG.AUTHOR,
> I.REPORTER) AS AUTHOR, COALESCE(CI.OLDVALUE, I.STATUS) AS STATUS, I.CREATED
> AS STARTDATE, CG.CREATED AS ENDDATE ",
> " FROM ISSUES AS I ",
> " JOIN INTERNAL.CHANGEGROUP AS CG ON CG.ISSUEID = I.ID ",
> " JOIN INTERNAL.CHANGEITEM AS CI ON CI.GROUPID = CG.ID ",
> " WHERE CI.FIELDTYPE = 'jira' AND CI.FIELD = 'status' ",
> " WINDOW w AS (PARTITION BY i.id ORDER BY CG.CREATED) ",
> ") ",
> "SELECT ISSUE, AUTHOR, STATUS, STARTDATE, ENDDATE ",
> "FROM ALLROWS WHERE ALLROWS.IDX <= 1 ",
> "UNION ALL ",
> "SELECT I.ID AS ISSUE, CG.AUTHOR, CI.NEWVALUE AS STATUS,
> CG.CREATED AS STARTDATE, LEAD(CG.CREATED, 1) OVER W AS ENDDATE ",
> "FROM ISSUES i ",
> "JOIN INTERNAL.CHANGEGROUP AS CG ON CG.ISSUEID = I.ID ",
> "JOIN INTERNAL.CHANGEITEM AS CI ON CI.GROUPID = CG.ID ",
> "WHERE CI.FIELDTYPE = 'jira' AND CI.FIELD = 'status' ",
> "WINDOW W AS (PARTITION BY I.ID ORDER BY CG.CREATED) "
> ]
> },
> {code}
> When performig
> {code:sql}
> SELECT * FROM STEPS
> {code}
> The result is
> {noformat}
> Line 1556, Column 0: Java$AmbiguousName is not allowed as an expression
> statement. Expressions statements must be one of assignments, method
> invocations, or object allocations..
> {noformat}
> As an attachment, I've attached implementation. Clearly the line 1555/1556 is
> wrong...
> I've discovered then, when removing *WHERE ALLROWS.IDX <= 1* - all is ok.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2511) Possible bug in parsing implementation of rown_num select
[
https://issues.apache.org/jira/browse/CALCITE-2511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Piotr Bojko updated CALCITE-2511:
-
Description:
I've found a possible bug.
With following view:
{code:json}
{
"name": "STEPS",
"type": "view",
"sql": [
"WITH ALLROWS AS ( ",
" SELECT ",
" ROW_NUMBER() OVER W AS IDX, I.ID ISSUE, COALESCE(CG.AUTHOR,
I.REPORTER) AS AUTHOR, COALESCE(CI.OLDVALUE, I.STATUS) AS STATUS, I.CREATED AS
STARTDATE, CG.CREATED AS ENDDATE ",
" FROM ISSUES AS I ",
" JOIN INTERNAL.CHANGEGROUP AS CG ON CG.ISSUEID = I.ID ",
" JOIN INTERNAL.CHANGEITEM AS CI ON CI.GROUPID = CG.ID ",
" WHERE CI.FIELDTYPE = 'jira' AND CI.FIELD = 'status' ",
" WINDOW w AS (PARTITION BY i.id ORDER BY CG.CREATED) ",
") ",
"SELECT ISSUE, AUTHOR, STATUS, STARTDATE, ENDDATE ",
"FROM ALLROWS WHERE ALLROWS.IDX <= 1 ",
"UNION ALL ",
"SELECT I.ID AS ISSUE, CG.AUTHOR, CI.NEWVALUE AS STATUS,
CG.CREATED AS STARTDATE, LEAD(CG.CREATED, 1) OVER W AS ENDDATE ",
"FROM ISSUES i ",
"JOIN INTERNAL.CHANGEGROUP AS CG ON CG.ISSUEID = I.ID ",
"JOIN INTERNAL.CHANGEITEM AS CI ON CI.GROUPID = CG.ID ",
"WHERE CI.FIELDTYPE = 'jira' AND CI.FIELD = 'status' ",
"WINDOW W AS (PARTITION BY I.ID ORDER BY CG.CREATED) "
]
},
{code}
When performig
{code:sql}
SELECT * FROM STEPS
{code}
The result is
{noformat}
Line 1556, Column 0: Java$AmbiguousName is not allowed as an expression
statement. Expressions statements must be one of assignments, method
invocations, or object allocations..
{noformat}
As an attachment, I've attached implementation. Clearly the line 1555/1556 is
wrong...
I've discovered then, when removing *WHERE ALLROWS.IDX <= 1* - all is ok.
was:
I've found a possible bug.
With following view:
{code:json}
{
"name": "STEPS",
"type": "view",
"sql": [
"WITH ALLROWS AS ( ",
" SELECT ",
" ROW_NUMBER() OVER W AS IDX,
I.ID ISSUE, COALESCE(CG.AUTHOR, I.REPORTER) AS AUTHOR, COALESCE(CI.OLDVALUE,
I.STATUS) AS STATUS, I.CREATED AS STARTDATE, CG.CREATED AS ENDDATE ",
" FROM ISSUES AS I ",
" JOIN INTERNAL.CHANGEGROUP AS
CG ON CG.ISSUEID = I.ID ",
" JOIN INTERNAL.CHANGEITEM AS
CI ON CI.GROUPID = CG.ID ",
" WHERE CI.FIELDTYPE = 'jira'
AND CI.FIELD = 'status' ",
" WINDOW w AS (PARTITION BY
i.id ORDER BY CG.CREATED) ",
") ",
"SELECT ISSUE, AUTHOR, STATUS,
STARTDATE, ENDDATE ",
"FROM ALLROWS WHERE ALLROWS.IDX
<= 1 ",
"UNION ALL ",
"SELECT I.ID AS ISSUE,
CG.AUTHOR, CI.NEWVALUE AS STATUS, CG.CREATED AS STARTDATE, LEAD(CG.CREATED, 1)
OVER W AS ENDDATE ",
"FROM ISSUES i ",
"JOIN INTERNAL.CHANGEGROUP AS
CG ON CG.ISSUEID = I.ID ",
"JOIN INTERNAL.CHANGEITEM AS CI
ON CI.GROUPID = CG.ID ",
"WHERE CI.FIELDTYPE = 'jira'
AND CI.FIELD = 'status' ",
"WINDOW W AS (PARTITION BY I.ID
ORDER BY CG.CREATED) "
]
},
{code}
When performig
{code:sql}
SELECT * FROM STEPS
{code}
The result is
{noformat}
Line 1556, Column 0: Java$AmbiguousName is not allowed as an expression
statement. Expressions statements must be one of assignments, method
invocations, or object allocations..
{noformat}
As an attachment, I've attached implementation. Clearly the line 1555/1556 is
wrong...
> Possible bug in parsing implementation of rown_num select
> -
>
> Key: CALCITE-2511
> URL: https://issues.apache.org/jira/browse/CALCITE-2511
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0, 1.18.0
>Reporter: Piotr Bojko
>Assignee: Julian
[jira] [Created] (CALCITE-2511) Possible bug in parsing implementation of rown_num select
Piotr Bojko created CALCITE-2511:
Summary: Possible bug in parsing implementation of rown_num select
Key: CALCITE-2511
URL: https://issues.apache.org/jira/browse/CALCITE-2511
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.17.0, 1.18.0
Reporter: Piotr Bojko
Assignee: Julian Hyde
Attachments: implementation.java
I've found a possible bug.
With following view:
{code:json}
{
"name": "STEPS",
"type": "view",
"sql": [
"WITH ALLROWS AS ( ",
" SELECT ",
" ROW_NUMBER() OVER W AS IDX,
I.ID ISSUE, COALESCE(CG.AUTHOR, I.REPORTER) AS AUTHOR, COALESCE(CI.OLDVALUE,
I.STATUS) AS STATUS, I.CREATED AS STARTDATE, CG.CREATED AS ENDDATE ",
" FROM ISSUES AS I ",
" JOIN INTERNAL.CHANGEGROUP AS
CG ON CG.ISSUEID = I.ID ",
" JOIN INTERNAL.CHANGEITEM AS
CI ON CI.GROUPID = CG.ID ",
" WHERE CI.FIELDTYPE = 'jira'
AND CI.FIELD = 'status' ",
" WINDOW w AS (PARTITION BY
i.id ORDER BY CG.CREATED) ",
") ",
"SELECT ISSUE, AUTHOR, STATUS,
STARTDATE, ENDDATE ",
"FROM ALLROWS WHERE ALLROWS.IDX
<= 1 ",
"UNION ALL ",
"SELECT I.ID AS ISSUE,
CG.AUTHOR, CI.NEWVALUE AS STATUS, CG.CREATED AS STARTDATE, LEAD(CG.CREATED, 1)
OVER W AS ENDDATE ",
"FROM ISSUES i ",
"JOIN INTERNAL.CHANGEGROUP AS
CG ON CG.ISSUEID = I.ID ",
"JOIN INTERNAL.CHANGEITEM AS CI
ON CI.GROUPID = CG.ID ",
"WHERE CI.FIELDTYPE = 'jira'
AND CI.FIELD = 'status' ",
"WINDOW W AS (PARTITION BY I.ID
ORDER BY CG.CREATED) "
]
},
{code}
When performig
{code:sql}
SELECT * FROM STEPS
{code}
The result is
{noformat}
Line 1556, Column 0: Java$AmbiguousName is not allowed as an expression
statement. Expressions statements must be one of assignments, method
invocations, or object allocations..
{noformat}
As an attachment, I've attached implementation. Clearly the line 1555/1556 is
wrong...
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2446) Lateral joins not work when saved as custom views
[
https://issues.apache.org/jira/browse/CALCITE-2446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16575329#comment-16575329
]
Piotr Bojko commented on CALCITE-2446:
--
I've squashed commits and make new comment for a commit.
I've added tests.
> Lateral joins not work when saved as custom views
> -
>
> Key: CALCITE-2446
> URL: https://issues.apache.org/jira/browse/CALCITE-2446
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: Piotr Bojko
>Assignee: Piotr Bojko
>Priority: Major
>
> See https://github.com/ptrbojko/calcite/tree/bug/CALCITE-2446 for reproduction
> {quote}Julian Hyde
> Thu, Aug 2, 9:39 PM (18 hours ago)
> to dev
> Sounds like an interesting bug in view expansion. Can you log a bug please.
> If possible create a test case in ServerTest (since I presume that it needs
> CREATE VIEW followed by a query).
> Julian
> > On Aug 2, 2018, at 4:50 AM, ptr.bo...@gmail.com wrote:
> >
> > Hello,
> >
> > I struggling with a strange case. Following query works for me:
> > SELECT *
> > FROM CORE.FILTERS F
> > CROSS JOIN LATERAL TABLE(AUX.TBLFUNCTION('somestring, F.aCOLLUMN)) tblfn
> >
> > But when it is placed as a view under a schema EXAMPLES with name
> > EXAMPLECOLLATERAL, following query won't work
> > SELECT * FROM EXAMPLES.EXAMPLECOLLATERAL
> >
> > It produces:
> >
> >> org.apache.calcite.runtime.CalciteContextException: At line 3, column 51:
> >> Table 'F' not found
> >> 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:783)
> >> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:768)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:4779)
> >> at
> >> org.apache.calcite.sql.validate.DelegatingScope.fullyQualify(DelegatingScope.java:330)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5527)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5490)
> >> at org.apache.calcite.sql.SqlIdentifier.accept(SqlIdentifier.java:334)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.deriveTypeImpl(SqlValidatorImpl.java:1627)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.deriveType(SqlValidatorImpl.java:1612)
> >> at
> >> org.apache.calcite.sql.SqlOperator.constructArgTypeList(SqlOperator.java:584)
> >> at org.apache.calcite.sql.SqlFunction.deriveType(SqlFunction.java:233)
> >> at org.apache.calcite.sql.SqlFunction.deriveType(SqlFunction.java:215)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5503)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5490)
> >> at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:138)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.deriveTypeImpl(SqlValidatorImpl.java:1627)
> >> at
> >> org.apache.calcite.sql.validate.ProcedureNamespace.validateImpl(ProcedureNamespace.java:53)
> >> at
> >> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:965)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:944)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.validateFrom(SqlValidatorImpl.java:3027)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.validateFrom(SqlValidatorImpl.java:3012)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.validateJoin(SqlValidatorImpl.java:3064)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.validateFrom(SqlValidatorImpl.java:3021)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3271)
> >> at
> >> org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:60)
> >> at
> >> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:965)
> >> at
> >>
[jira] [Assigned] (CALCITE-2446) Lateral joins not work when saved as custom views
[
https://issues.apache.org/jira/browse/CALCITE-2446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Piotr Bojko reassigned CALCITE-2446:
Assignee: Julian Hyde (was: Piotr Bojko)
> Lateral joins not work when saved as custom views
> -
>
> Key: CALCITE-2446
> URL: https://issues.apache.org/jira/browse/CALCITE-2446
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: Piotr Bojko
>Assignee: Julian Hyde
>Priority: Major
>
> See https://github.com/ptrbojko/calcite/tree/bug/CALCITE-2446 for reproduction
> {quote}Julian Hyde
> Thu, Aug 2, 9:39 PM (18 hours ago)
> to dev
> Sounds like an interesting bug in view expansion. Can you log a bug please.
> If possible create a test case in ServerTest (since I presume that it needs
> CREATE VIEW followed by a query).
> Julian
> > On Aug 2, 2018, at 4:50 AM, ptr.bo...@gmail.com wrote:
> >
> > Hello,
> >
> > I struggling with a strange case. Following query works for me:
> > SELECT *
> > FROM CORE.FILTERS F
> > CROSS JOIN LATERAL TABLE(AUX.TBLFUNCTION('somestring, F.aCOLLUMN)) tblfn
> >
> > But when it is placed as a view under a schema EXAMPLES with name
> > EXAMPLECOLLATERAL, following query won't work
> > SELECT * FROM EXAMPLES.EXAMPLECOLLATERAL
> >
> > It produces:
> >
> >> org.apache.calcite.runtime.CalciteContextException: At line 3, column 51:
> >> Table 'F' not found
> >> 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:783)
> >> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:768)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:4779)
> >> at
> >> org.apache.calcite.sql.validate.DelegatingScope.fullyQualify(DelegatingScope.java:330)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5527)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5490)
> >> at org.apache.calcite.sql.SqlIdentifier.accept(SqlIdentifier.java:334)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.deriveTypeImpl(SqlValidatorImpl.java:1627)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.deriveType(SqlValidatorImpl.java:1612)
> >> at
> >> org.apache.calcite.sql.SqlOperator.constructArgTypeList(SqlOperator.java:584)
> >> at org.apache.calcite.sql.SqlFunction.deriveType(SqlFunction.java:233)
> >> at org.apache.calcite.sql.SqlFunction.deriveType(SqlFunction.java:215)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5503)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5490)
> >> at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:138)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.deriveTypeImpl(SqlValidatorImpl.java:1627)
> >> at
> >> org.apache.calcite.sql.validate.ProcedureNamespace.validateImpl(ProcedureNamespace.java:53)
> >> at
> >> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:965)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:944)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.validateFrom(SqlValidatorImpl.java:3027)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.validateFrom(SqlValidatorImpl.java:3012)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.validateJoin(SqlValidatorImpl.java:3064)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.validateFrom(SqlValidatorImpl.java:3021)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3271)
> >> at
> >> org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:60)
> >> at
> >> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:965)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:944)
> >> at
[jira] [Assigned] (CALCITE-2446) Lateral joins not work when saved as custom views
[
https://issues.apache.org/jira/browse/CALCITE-2446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Piotr Bojko reassigned CALCITE-2446:
Assignee: Piotr Bojko (was: Julian Hyde)
> Lateral joins not work when saved as custom views
> -
>
> Key: CALCITE-2446
> URL: https://issues.apache.org/jira/browse/CALCITE-2446
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: Piotr Bojko
>Assignee: Piotr Bojko
>Priority: Major
>
> See https://github.com/ptrbojko/calcite/tree/bug/CALCITE-2446 for reproduction
> {quote}Julian Hyde
> Thu, Aug 2, 9:39 PM (18 hours ago)
> to dev
> Sounds like an interesting bug in view expansion. Can you log a bug please.
> If possible create a test case in ServerTest (since I presume that it needs
> CREATE VIEW followed by a query).
> Julian
> > On Aug 2, 2018, at 4:50 AM, ptr.bo...@gmail.com wrote:
> >
> > Hello,
> >
> > I struggling with a strange case. Following query works for me:
> > SELECT *
> > FROM CORE.FILTERS F
> > CROSS JOIN LATERAL TABLE(AUX.TBLFUNCTION('somestring, F.aCOLLUMN)) tblfn
> >
> > But when it is placed as a view under a schema EXAMPLES with name
> > EXAMPLECOLLATERAL, following query won't work
> > SELECT * FROM EXAMPLES.EXAMPLECOLLATERAL
> >
> > It produces:
> >
> >> org.apache.calcite.runtime.CalciteContextException: At line 3, column 51:
> >> Table 'F' not found
> >> 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:783)
> >> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:768)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:4779)
> >> at
> >> org.apache.calcite.sql.validate.DelegatingScope.fullyQualify(DelegatingScope.java:330)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5527)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5490)
> >> at org.apache.calcite.sql.SqlIdentifier.accept(SqlIdentifier.java:334)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.deriveTypeImpl(SqlValidatorImpl.java:1627)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.deriveType(SqlValidatorImpl.java:1612)
> >> at
> >> org.apache.calcite.sql.SqlOperator.constructArgTypeList(SqlOperator.java:584)
> >> at org.apache.calcite.sql.SqlFunction.deriveType(SqlFunction.java:233)
> >> at org.apache.calcite.sql.SqlFunction.deriveType(SqlFunction.java:215)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5503)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5490)
> >> at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:138)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.deriveTypeImpl(SqlValidatorImpl.java:1627)
> >> at
> >> org.apache.calcite.sql.validate.ProcedureNamespace.validateImpl(ProcedureNamespace.java:53)
> >> at
> >> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:965)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:944)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.validateFrom(SqlValidatorImpl.java:3027)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.validateFrom(SqlValidatorImpl.java:3012)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.validateJoin(SqlValidatorImpl.java:3064)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.validateFrom(SqlValidatorImpl.java:3021)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3271)
> >> at
> >> org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:60)
> >> at
> >> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:965)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:944)
> >> at
[jira] [Commented] (CALCITE-2446) Lateral joins not work when saved as custom views
[
https://issues.apache.org/jira/browse/CALCITE-2446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16571430#comment-16571430
]
Piotr Bojko commented on CALCITE-2446:
--
I've pushed the pull with a fix. It removes validation from view expansion.
https://github.com/apache/calcite/pull/780
> Lateral joins not work when saved as custom views
> -
>
> Key: CALCITE-2446
> URL: https://issues.apache.org/jira/browse/CALCITE-2446
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: Piotr Bojko
>Assignee: Julian Hyde
>Priority: Major
>
> See https://github.com/ptrbojko/calcite/tree/bug/CALCITE-2446 for reproduction
> {quote}Julian Hyde
> Thu, Aug 2, 9:39 PM (18 hours ago)
> to dev
> Sounds like an interesting bug in view expansion. Can you log a bug please.
> If possible create a test case in ServerTest (since I presume that it needs
> CREATE VIEW followed by a query).
> Julian
> > On Aug 2, 2018, at 4:50 AM, ptr.bo...@gmail.com wrote:
> >
> > Hello,
> >
> > I struggling with a strange case. Following query works for me:
> > SELECT *
> > FROM CORE.FILTERS F
> > CROSS JOIN LATERAL TABLE(AUX.TBLFUNCTION('somestring, F.aCOLLUMN)) tblfn
> >
> > But when it is placed as a view under a schema EXAMPLES with name
> > EXAMPLECOLLATERAL, following query won't work
> > SELECT * FROM EXAMPLES.EXAMPLECOLLATERAL
> >
> > It produces:
> >
> >> org.apache.calcite.runtime.CalciteContextException: At line 3, column 51:
> >> Table 'F' not found
> >> 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:783)
> >> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:768)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:4779)
> >> at
> >> org.apache.calcite.sql.validate.DelegatingScope.fullyQualify(DelegatingScope.java:330)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5527)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5490)
> >> at org.apache.calcite.sql.SqlIdentifier.accept(SqlIdentifier.java:334)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.deriveTypeImpl(SqlValidatorImpl.java:1627)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.deriveType(SqlValidatorImpl.java:1612)
> >> at
> >> org.apache.calcite.sql.SqlOperator.constructArgTypeList(SqlOperator.java:584)
> >> at org.apache.calcite.sql.SqlFunction.deriveType(SqlFunction.java:233)
> >> at org.apache.calcite.sql.SqlFunction.deriveType(SqlFunction.java:215)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5503)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5490)
> >> at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:138)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.deriveTypeImpl(SqlValidatorImpl.java:1627)
> >> at
> >> org.apache.calcite.sql.validate.ProcedureNamespace.validateImpl(ProcedureNamespace.java:53)
> >> at
> >> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:965)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:944)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.validateFrom(SqlValidatorImpl.java:3027)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.validateFrom(SqlValidatorImpl.java:3012)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.validateJoin(SqlValidatorImpl.java:3064)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.validateFrom(SqlValidatorImpl.java:3021)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3271)
> >> at
> >> org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:60)
> >> at
> >> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:965)
> >> at
> >>
[jira] [Comment Edited] (CALCITE-2446) Lateral joins not work when saved as custom views
[
https://issues.apache.org/jira/browse/CALCITE-2446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16570247#comment-16570247
]
Piotr Bojko edited comment on CALCITE-2446 at 8/6/18 2:16 PM:
--
I'm not sure on how to fix the mentioned bug.
I have one big doubt on this - why during view expansion does Calcite validate
the sql nodes? This will be done twice for queries with views.
I've removed sqlvalidation from CalcitePrepareImpl.expandView (lines 1182~1185)
- and only one test from calcite has failed
(SqlValidatorTest.testDynamicStar2). But it works for the mentioned bug.
was (Author: ptrbojko):
I'm not sure on how to fix the mentioned bug.
I've have one big doubt on this - why during view expansion does Calcite
validate the sql nodes? This will be done twice for queries with views.
I've removed sqlvalidation from CalcitePrepareImpl.expandView (lines 1182~1185)
- and only one test from calcite has failed
(SqlValidatorTest.testDynamicStar2). But it works for the mentioned bug.
> Lateral joins not work when saved as custom views
> -
>
> Key: CALCITE-2446
> URL: https://issues.apache.org/jira/browse/CALCITE-2446
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: Piotr Bojko
>Assignee: Julian Hyde
>Priority: Major
>
> See https://github.com/ptrbojko/calcite/tree/bug/CALCITE-2446 for reproduction
> {quote}Julian Hyde
> Thu, Aug 2, 9:39 PM (18 hours ago)
> to dev
> Sounds like an interesting bug in view expansion. Can you log a bug please.
> If possible create a test case in ServerTest (since I presume that it needs
> CREATE VIEW followed by a query).
> Julian
> > On Aug 2, 2018, at 4:50 AM, ptr.bo...@gmail.com wrote:
> >
> > Hello,
> >
> > I struggling with a strange case. Following query works for me:
> > SELECT *
> > FROM CORE.FILTERS F
> > CROSS JOIN LATERAL TABLE(AUX.TBLFUNCTION('somestring, F.aCOLLUMN)) tblfn
> >
> > But when it is placed as a view under a schema EXAMPLES with name
> > EXAMPLECOLLATERAL, following query won't work
> > SELECT * FROM EXAMPLES.EXAMPLECOLLATERAL
> >
> > It produces:
> >
> >> org.apache.calcite.runtime.CalciteContextException: At line 3, column 51:
> >> Table 'F' not found
> >> 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:783)
> >> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:768)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:4779)
> >> at
> >> org.apache.calcite.sql.validate.DelegatingScope.fullyQualify(DelegatingScope.java:330)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5527)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5490)
> >> at org.apache.calcite.sql.SqlIdentifier.accept(SqlIdentifier.java:334)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.deriveTypeImpl(SqlValidatorImpl.java:1627)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.deriveType(SqlValidatorImpl.java:1612)
> >> at
> >> org.apache.calcite.sql.SqlOperator.constructArgTypeList(SqlOperator.java:584)
> >> at org.apache.calcite.sql.SqlFunction.deriveType(SqlFunction.java:233)
> >> at org.apache.calcite.sql.SqlFunction.deriveType(SqlFunction.java:215)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5503)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5490)
> >> at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:138)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.deriveTypeImpl(SqlValidatorImpl.java:1627)
> >> at
> >> org.apache.calcite.sql.validate.ProcedureNamespace.validateImpl(ProcedureNamespace.java:53)
> >> at
> >> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:965)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:944)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.validateFrom(SqlValidatorImpl.java:3027)
> >> at
> >>
[jira] [Comment Edited] (CALCITE-2446) Lateral joins not work when saved as custom views
[
https://issues.apache.org/jira/browse/CALCITE-2446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16570222#comment-16570222
]
Piotr Bojko edited comment on CALCITE-2446 at 8/6/18 2:15 PM:
--
I've found that SqlValidatorImpl during view expansion is rewriting SqlNode's
(SqlValidatorImpl.registerFrom --> case LATERAL, lines 2161-2171) and then
registering TableScope.
But during expansion - no scopes from this phase are used, only rewritten sql
nodes. Thus, when the whole parent query with expanded view is validated again,
information about lateral join is missing and invalid scope is then generated
for_ JOIN (non-lateral but should be lateral) TABLE(fn)_ part.
was (Author: ptrbojko):
I've found that SqlValidatorImpl during view expansion is rewriting SqlNode's
(SqlValidatorImpl.registerFrom --> case LATERAL, lines 2161-2171) and then
registering TableScope.
But during expansion - no scopes from this phase are used, only rewritten sql
nodes. Thus, when the whole parent query with expanded view is validated again,
information about lateral join is missing and invalid scope is then generated
for_ JOIN (non-lateral but shut be lateral) TABLE(fn)_ part.
> Lateral joins not work when saved as custom views
> -
>
> Key: CALCITE-2446
> URL: https://issues.apache.org/jira/browse/CALCITE-2446
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: Piotr Bojko
>Assignee: Julian Hyde
>Priority: Major
>
> See https://github.com/ptrbojko/calcite/tree/bug/CALCITE-2446 for reproduction
> {quote}Julian Hyde
> Thu, Aug 2, 9:39 PM (18 hours ago)
> to dev
> Sounds like an interesting bug in view expansion. Can you log a bug please.
> If possible create a test case in ServerTest (since I presume that it needs
> CREATE VIEW followed by a query).
> Julian
> > On Aug 2, 2018, at 4:50 AM, ptr.bo...@gmail.com wrote:
> >
> > Hello,
> >
> > I struggling with a strange case. Following query works for me:
> > SELECT *
> > FROM CORE.FILTERS F
> > CROSS JOIN LATERAL TABLE(AUX.TBLFUNCTION('somestring, F.aCOLLUMN)) tblfn
> >
> > But when it is placed as a view under a schema EXAMPLES with name
> > EXAMPLECOLLATERAL, following query won't work
> > SELECT * FROM EXAMPLES.EXAMPLECOLLATERAL
> >
> > It produces:
> >
> >> org.apache.calcite.runtime.CalciteContextException: At line 3, column 51:
> >> Table 'F' not found
> >> 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:783)
> >> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:768)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:4779)
> >> at
> >> org.apache.calcite.sql.validate.DelegatingScope.fullyQualify(DelegatingScope.java:330)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5527)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5490)
> >> at org.apache.calcite.sql.SqlIdentifier.accept(SqlIdentifier.java:334)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.deriveTypeImpl(SqlValidatorImpl.java:1627)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.deriveType(SqlValidatorImpl.java:1612)
> >> at
> >> org.apache.calcite.sql.SqlOperator.constructArgTypeList(SqlOperator.java:584)
> >> at org.apache.calcite.sql.SqlFunction.deriveType(SqlFunction.java:233)
> >> at org.apache.calcite.sql.SqlFunction.deriveType(SqlFunction.java:215)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5503)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5490)
> >> at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:138)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.deriveTypeImpl(SqlValidatorImpl.java:1627)
> >> at
> >> org.apache.calcite.sql.validate.ProcedureNamespace.validateImpl(ProcedureNamespace.java:53)
> >> at
> >> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:965)
> >> at
> >>
[jira] [Commented] (CALCITE-2446) Lateral joins not work when saved as custom views
[
https://issues.apache.org/jira/browse/CALCITE-2446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16570247#comment-16570247
]
Piotr Bojko commented on CALCITE-2446:
--
I'm not sure on how to fix the mentioned bug.
I've have one big doubt on this - why during view expansion does Calcite
validate the sql nodes? This will be done twice for queries with views.
I've removed sqlvalidation from CalcitePrepareImpl.expandView (lines 1182~1185)
- and only one test from calcite has failed
(SqlValidatorTest.testDynamicStar2). But it works for the mentioned bug.
> Lateral joins not work when saved as custom views
> -
>
> Key: CALCITE-2446
> URL: https://issues.apache.org/jira/browse/CALCITE-2446
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: Piotr Bojko
>Assignee: Julian Hyde
>Priority: Major
>
> See https://github.com/ptrbojko/calcite/tree/bug/CALCITE-2446 for reproduction
> {quote}Julian Hyde
> Thu, Aug 2, 9:39 PM (18 hours ago)
> to dev
> Sounds like an interesting bug in view expansion. Can you log a bug please.
> If possible create a test case in ServerTest (since I presume that it needs
> CREATE VIEW followed by a query).
> Julian
> > On Aug 2, 2018, at 4:50 AM, ptr.bo...@gmail.com wrote:
> >
> > Hello,
> >
> > I struggling with a strange case. Following query works for me:
> > SELECT *
> > FROM CORE.FILTERS F
> > CROSS JOIN LATERAL TABLE(AUX.TBLFUNCTION('somestring, F.aCOLLUMN)) tblfn
> >
> > But when it is placed as a view under a schema EXAMPLES with name
> > EXAMPLECOLLATERAL, following query won't work
> > SELECT * FROM EXAMPLES.EXAMPLECOLLATERAL
> >
> > It produces:
> >
> >> org.apache.calcite.runtime.CalciteContextException: At line 3, column 51:
> >> Table 'F' not found
> >> 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:783)
> >> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:768)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:4779)
> >> at
> >> org.apache.calcite.sql.validate.DelegatingScope.fullyQualify(DelegatingScope.java:330)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5527)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5490)
> >> at org.apache.calcite.sql.SqlIdentifier.accept(SqlIdentifier.java:334)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.deriveTypeImpl(SqlValidatorImpl.java:1627)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.deriveType(SqlValidatorImpl.java:1612)
> >> at
> >> org.apache.calcite.sql.SqlOperator.constructArgTypeList(SqlOperator.java:584)
> >> at org.apache.calcite.sql.SqlFunction.deriveType(SqlFunction.java:233)
> >> at org.apache.calcite.sql.SqlFunction.deriveType(SqlFunction.java:215)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5503)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5490)
> >> at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:138)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.deriveTypeImpl(SqlValidatorImpl.java:1627)
> >> at
> >> org.apache.calcite.sql.validate.ProcedureNamespace.validateImpl(ProcedureNamespace.java:53)
> >> at
> >> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:965)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:944)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.validateFrom(SqlValidatorImpl.java:3027)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.validateFrom(SqlValidatorImpl.java:3012)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.validateJoin(SqlValidatorImpl.java:3064)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.validateFrom(SqlValidatorImpl.java:3021)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3271)
> >> at
> >>
[jira] [Commented] (CALCITE-2446) Lateral joins not work when saved as custom views
[
https://issues.apache.org/jira/browse/CALCITE-2446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16570222#comment-16570222
]
Piotr Bojko commented on CALCITE-2446:
--
I've found that SqlValidatorImpl during view expansion is rewriting SqlNode's
(SqlValidatorImpl.registerFrom --> case LATERAL, lines 2161-2171) and then
registering TableScope.
But during expansion - no scopes from this phase are used, only rewritten sql
nodes. Thus, when the whole parent query with expanded view is validated again,
information about lateral join is missing and invalid scope is then generated
for_ JOIN (non-lateral but shut be lateral) TABLE(fn)_ part.
> Lateral joins not work when saved as custom views
> -
>
> Key: CALCITE-2446
> URL: https://issues.apache.org/jira/browse/CALCITE-2446
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: Piotr Bojko
>Assignee: Julian Hyde
>Priority: Major
>
> See https://github.com/ptrbojko/calcite/tree/bug/CALCITE-2446 for reproduction
> {quote}Julian Hyde
> Thu, Aug 2, 9:39 PM (18 hours ago)
> to dev
> Sounds like an interesting bug in view expansion. Can you log a bug please.
> If possible create a test case in ServerTest (since I presume that it needs
> CREATE VIEW followed by a query).
> Julian
> > On Aug 2, 2018, at 4:50 AM, ptr.bo...@gmail.com wrote:
> >
> > Hello,
> >
> > I struggling with a strange case. Following query works for me:
> > SELECT *
> > FROM CORE.FILTERS F
> > CROSS JOIN LATERAL TABLE(AUX.TBLFUNCTION('somestring, F.aCOLLUMN)) tblfn
> >
> > But when it is placed as a view under a schema EXAMPLES with name
> > EXAMPLECOLLATERAL, following query won't work
> > SELECT * FROM EXAMPLES.EXAMPLECOLLATERAL
> >
> > It produces:
> >
> >> org.apache.calcite.runtime.CalciteContextException: At line 3, column 51:
> >> Table 'F' not found
> >> 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:783)
> >> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:768)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:4779)
> >> at
> >> org.apache.calcite.sql.validate.DelegatingScope.fullyQualify(DelegatingScope.java:330)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5527)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5490)
> >> at org.apache.calcite.sql.SqlIdentifier.accept(SqlIdentifier.java:334)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.deriveTypeImpl(SqlValidatorImpl.java:1627)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.deriveType(SqlValidatorImpl.java:1612)
> >> at
> >> org.apache.calcite.sql.SqlOperator.constructArgTypeList(SqlOperator.java:584)
> >> at org.apache.calcite.sql.SqlFunction.deriveType(SqlFunction.java:233)
> >> at org.apache.calcite.sql.SqlFunction.deriveType(SqlFunction.java:215)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5503)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5490)
> >> at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:138)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.deriveTypeImpl(SqlValidatorImpl.java:1627)
> >> at
> >> org.apache.calcite.sql.validate.ProcedureNamespace.validateImpl(ProcedureNamespace.java:53)
> >> at
> >> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:965)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:944)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.validateFrom(SqlValidatorImpl.java:3027)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.validateFrom(SqlValidatorImpl.java:3012)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.validateJoin(SqlValidatorImpl.java:3064)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.validateFrom(SqlValidatorImpl.java:3021)
> >> at
> >>
[jira] [Comment Edited] (CALCITE-2446) Lateral joins not work when saved as custom views
[
https://issues.apache.org/jira/browse/CALCITE-2446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16570111#comment-16570111
]
Piotr Bojko edited comment on CALCITE-2446 at 8/6/18 1:03 PM:
--
After messing with debug, some maybe faulty thought is that when expanding view
- cross join lateral is expanded as a simple inner join (non-lateral).
Found - validating step.
was (Author: ptrbojko):
After messing with debug, some maybe faulty thought is that when expanding view
- cross join lateral is expanded as a simple inner join (non-lateral).
> Lateral joins not work when saved as custom views
> -
>
> Key: CALCITE-2446
> URL: https://issues.apache.org/jira/browse/CALCITE-2446
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: Piotr Bojko
>Assignee: Julian Hyde
>Priority: Major
>
> See https://github.com/ptrbojko/calcite/tree/bug/CALCITE-2446 for reproduction
> {quote}Julian Hyde
> Thu, Aug 2, 9:39 PM (18 hours ago)
> to dev
> Sounds like an interesting bug in view expansion. Can you log a bug please.
> If possible create a test case in ServerTest (since I presume that it needs
> CREATE VIEW followed by a query).
> Julian
> > On Aug 2, 2018, at 4:50 AM, ptr.bo...@gmail.com wrote:
> >
> > Hello,
> >
> > I struggling with a strange case. Following query works for me:
> > SELECT *
> > FROM CORE.FILTERS F
> > CROSS JOIN LATERAL TABLE(AUX.TBLFUNCTION('somestring, F.aCOLLUMN)) tblfn
> >
> > But when it is placed as a view under a schema EXAMPLES with name
> > EXAMPLECOLLATERAL, following query won't work
> > SELECT * FROM EXAMPLES.EXAMPLECOLLATERAL
> >
> > It produces:
> >
> >> org.apache.calcite.runtime.CalciteContextException: At line 3, column 51:
> >> Table 'F' not found
> >> 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:783)
> >> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:768)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:4779)
> >> at
> >> org.apache.calcite.sql.validate.DelegatingScope.fullyQualify(DelegatingScope.java:330)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5527)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5490)
> >> at org.apache.calcite.sql.SqlIdentifier.accept(SqlIdentifier.java:334)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.deriveTypeImpl(SqlValidatorImpl.java:1627)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.deriveType(SqlValidatorImpl.java:1612)
> >> at
> >> org.apache.calcite.sql.SqlOperator.constructArgTypeList(SqlOperator.java:584)
> >> at org.apache.calcite.sql.SqlFunction.deriveType(SqlFunction.java:233)
> >> at org.apache.calcite.sql.SqlFunction.deriveType(SqlFunction.java:215)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5503)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5490)
> >> at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:138)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.deriveTypeImpl(SqlValidatorImpl.java:1627)
> >> at
> >> org.apache.calcite.sql.validate.ProcedureNamespace.validateImpl(ProcedureNamespace.java:53)
> >> at
> >> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:965)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:944)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.validateFrom(SqlValidatorImpl.java:3027)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.validateFrom(SqlValidatorImpl.java:3012)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.validateJoin(SqlValidatorImpl.java:3064)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.validateFrom(SqlValidatorImpl.java:3021)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3271)
> >> at
> >>
[jira] [Commented] (CALCITE-2446) Lateral joins not work when saved as custom views
[
https://issues.apache.org/jira/browse/CALCITE-2446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16570111#comment-16570111
]
Piotr Bojko commented on CALCITE-2446:
--
After messing with debug, some maybe faulty thought is that when expanding view
- cross join lateral is expanded as a simple inner join (non-lateral).
> Lateral joins not work when saved as custom views
> -
>
> Key: CALCITE-2446
> URL: https://issues.apache.org/jira/browse/CALCITE-2446
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: Piotr Bojko
>Assignee: Julian Hyde
>Priority: Major
>
> See https://github.com/ptrbojko/calcite/tree/bug/CALCITE-2446 for reproduction
> {quote}Julian Hyde
> Thu, Aug 2, 9:39 PM (18 hours ago)
> to dev
> Sounds like an interesting bug in view expansion. Can you log a bug please.
> If possible create a test case in ServerTest (since I presume that it needs
> CREATE VIEW followed by a query).
> Julian
> > On Aug 2, 2018, at 4:50 AM, ptr.bo...@gmail.com wrote:
> >
> > Hello,
> >
> > I struggling with a strange case. Following query works for me:
> > SELECT *
> > FROM CORE.FILTERS F
> > CROSS JOIN LATERAL TABLE(AUX.TBLFUNCTION('somestring, F.aCOLLUMN)) tblfn
> >
> > But when it is placed as a view under a schema EXAMPLES with name
> > EXAMPLECOLLATERAL, following query won't work
> > SELECT * FROM EXAMPLES.EXAMPLECOLLATERAL
> >
> > It produces:
> >
> >> org.apache.calcite.runtime.CalciteContextException: At line 3, column 51:
> >> Table 'F' not found
> >> 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:783)
> >> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:768)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:4779)
> >> at
> >> org.apache.calcite.sql.validate.DelegatingScope.fullyQualify(DelegatingScope.java:330)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5527)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5490)
> >> at org.apache.calcite.sql.SqlIdentifier.accept(SqlIdentifier.java:334)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.deriveTypeImpl(SqlValidatorImpl.java:1627)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.deriveType(SqlValidatorImpl.java:1612)
> >> at
> >> org.apache.calcite.sql.SqlOperator.constructArgTypeList(SqlOperator.java:584)
> >> at org.apache.calcite.sql.SqlFunction.deriveType(SqlFunction.java:233)
> >> at org.apache.calcite.sql.SqlFunction.deriveType(SqlFunction.java:215)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5503)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5490)
> >> at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:138)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.deriveTypeImpl(SqlValidatorImpl.java:1627)
> >> at
> >> org.apache.calcite.sql.validate.ProcedureNamespace.validateImpl(ProcedureNamespace.java:53)
> >> at
> >> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:965)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:944)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.validateFrom(SqlValidatorImpl.java:3027)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.validateFrom(SqlValidatorImpl.java:3012)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.validateJoin(SqlValidatorImpl.java:3064)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.validateFrom(SqlValidatorImpl.java:3021)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3271)
> >> at
> >> org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:60)
> >> at
> >> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84)
> >> at
> >> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:965)
> >> at
> >>
[jira] [Updated] (CALCITE-2446) Lateral joins not work when saved as custom views
[
https://issues.apache.org/jira/browse/CALCITE-2446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Piotr Bojko updated CALCITE-2446:
-
Description:
See https://github.com/ptrbojko/calcite/tree/bug/CALCITE-2446 for reproduction
{quote}Julian Hyde
Thu, Aug 2, 9:39 PM (18 hours ago)
to dev
Sounds like an interesting bug in view expansion. Can you log a bug please. If
possible create a test case in ServerTest (since I presume that it needs CREATE
VIEW followed by a query).
Julian
> On Aug 2, 2018, at 4:50 AM, ptr.bo...@gmail.com wrote:
>
> Hello,
>
> I struggling with a strange case. Following query works for me:
> SELECT *
> FROM CORE.FILTERS F
> CROSS JOIN LATERAL TABLE(AUX.TBLFUNCTION('somestring, F.aCOLLUMN)) tblfn
>
> But when it is placed as a view under a schema EXAMPLES with name
> EXAMPLECOLLATERAL, following query won't work
> SELECT * FROM EXAMPLES.EXAMPLECOLLATERAL
>
> It produces:
>
>> org.apache.calcite.runtime.CalciteContextException: At line 3, column 51:
>> Table 'F' not found
>> 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:783)
>> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:768)
>> at
>> org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:4779)
>> at
>> org.apache.calcite.sql.validate.DelegatingScope.fullyQualify(DelegatingScope.java:330)
>> at
>> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5527)
>> at
>> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5490)
>> at org.apache.calcite.sql.SqlIdentifier.accept(SqlIdentifier.java:334)
>> at
>> org.apache.calcite.sql.validate.SqlValidatorImpl.deriveTypeImpl(SqlValidatorImpl.java:1627)
>> at
>> org.apache.calcite.sql.validate.SqlValidatorImpl.deriveType(SqlValidatorImpl.java:1612)
>> at
>> org.apache.calcite.sql.SqlOperator.constructArgTypeList(SqlOperator.java:584)
>> at org.apache.calcite.sql.SqlFunction.deriveType(SqlFunction.java:233)
>> at org.apache.calcite.sql.SqlFunction.deriveType(SqlFunction.java:215)
>> at
>> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5503)
>> at
>> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5490)
>> at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:138)
>> at
>> org.apache.calcite.sql.validate.SqlValidatorImpl.deriveTypeImpl(SqlValidatorImpl.java:1627)
>> at
>> org.apache.calcite.sql.validate.ProcedureNamespace.validateImpl(ProcedureNamespace.java:53)
>> at
>> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84)
>> at
>> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:965)
>> at
>> org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:944)
>> at
>> org.apache.calcite.sql.validate.SqlValidatorImpl.validateFrom(SqlValidatorImpl.java:3027)
>> at
>> org.apache.calcite.sql.validate.SqlValidatorImpl.validateFrom(SqlValidatorImpl.java:3012)
>> at
>> org.apache.calcite.sql.validate.SqlValidatorImpl.validateJoin(SqlValidatorImpl.java:3064)
>> at
>> org.apache.calcite.sql.validate.SqlValidatorImpl.validateFrom(SqlValidatorImpl.java:3021)
>> at
>> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3271)
>> at
>> org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:60)
>> at
>> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84)
>> at
>> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:965)
>> at
>> org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:944)
>> at org.apache.calcite.sql.SqlSelect.validate(SqlSelect.java:225)
>> at
>> org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:919)
>> at
>> org.apache.calcite.sql.validate.SqlValidatorImpl.validate(SqlValidatorImpl.java:629)
>> at
>> org.apache.calcite.prepare.CalcitePrepareImpl.parse_(CalcitePrepareImpl.java:292)
>
>
> I am willing to patch this if this is a bug - just need a point to the
> right direction.
>
> Thanx!
> --
> Piotr Bojko
> http://about.me/ptr.bojko
{quote}
was:to be updated
> Lateral joins not work when saved as custom views
> -
>
>
[jira] [Created] (CALCITE-2446) Lateral joins not work when saved as custom views
Piotr Bojko created CALCITE-2446: Summary: Lateral joins not work when saved as custom views Key: CALCITE-2446 URL: https://issues.apache.org/jira/browse/CALCITE-2446 Project: Calcite Issue Type: Bug Components: core Affects Versions: 1.17.0 Reporter: Piotr Bojko Assignee: Julian Hyde to be updated -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2420) Aggregate functions MIN/MAX does not work for Timestamp
[ https://issues.apache.org/jira/browse/CALCITE-2420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16551619#comment-16551619 ] Piotr Bojko commented on CALCITE-2420: -- This ticket can be rejected. > Aggregate functions MIN/MAX does not work for Timestamp > --- > > Key: CALCITE-2420 > URL: https://issues.apache.org/jira/browse/CALCITE-2420 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.17.0 >Reporter: Piotr Bojko >Assignee: Julian Hyde >Priority: Major > > See https://github.com/ptrbojko/calcite/tree/CALCITE-2420 for reproduction. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2420) Aggregate functions MIN/MAX does not work for Timestamp
[ https://issues.apache.org/jira/browse/CALCITE-2420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16548939#comment-16548939 ] Piotr Bojko commented on CALCITE-2420: -- Thx, after changing to SqlType and switching to Long at tbl function implementation everything seems to work now. Using primitives instead of timestamp/date/.. at the client level is counter intuitive though. See ShufflePlaylistGeneratorFunction, this is a kind of a client level code and there is no reason to use it internal representations, like primitives instead of objects with their proper business type (Timestamp). > Aggregate functions MIN/MAX does not work for Timestamp > --- > > Key: CALCITE-2420 > URL: https://issues.apache.org/jira/browse/CALCITE-2420 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.17.0 >Reporter: Piotr Bojko >Assignee: Julian Hyde >Priority: Major > > See https://github.com/ptrbojko/calcite/tree/CALCITE-2420 for reproduction. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2420) Aggregate functions MIN/MAX does not work for Timestamp
[ https://issues.apache.org/jira/browse/CALCITE-2420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Piotr Bojko updated CALCITE-2420: - Description: See https://github.com/ptrbojko/calcite/tree/CALCITE-2420 for reproduction. > Aggregate functions MIN/MAX does not work for Timestamp > --- > > Key: CALCITE-2420 > URL: https://issues.apache.org/jira/browse/CALCITE-2420 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.17.0 >Reporter: Piotr Bojko >Assignee: Julian Hyde >Priority: Major > > See https://github.com/ptrbojko/calcite/tree/CALCITE-2420 for reproduction. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-2420) Aggregate functions MIN/MAX does not work for Timestamp
Piotr Bojko created CALCITE-2420: Summary: Aggregate functions MIN/MAX does not work for Timestamp Key: CALCITE-2420 URL: https://issues.apache.org/jira/browse/CALCITE-2420 Project: Calcite Issue Type: Bug Components: core Affects Versions: 1.17.0 Reporter: Piotr Bojko Assignee: Julian Hyde -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (CALCITE-2320) UDF in WHERE expression incorrectly pushed down to jdbc schema
[
https://issues.apache.org/jira/browse/CALCITE-2320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Piotr Bojko reassigned CALCITE-2320:
Assignee: Piotr Bojko (was: Julian Hyde)
> UDF in WHERE expression incorrectly pushed down to jdbc schema
> --
>
> Key: CALCITE-2320
> URL: https://issues.apache.org/jira/browse/CALCITE-2320
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.16.0, 1.17.0
>Reporter: Piotr Bojko
>Assignee: Piotr Bojko
>Priority: Major
> Fix For: 1.17.0
>
>
> # Checks whether CHOOSENCUSTOMFUNCTION function is properly computed and not
> passed to subschema, like jdbc
> SELECT * FROM SIMPLE_CUSTOMER WHERE email = CHOOSENCUSTOMER();
> where CHOOSENCUSTOMER is UDF leads to
> {code}
> Caused by: java.lang.RuntimeException: while executing SQL [SELECT
> "FIRSTNAME", "LASTNAME", "EMAIL"
> > FROM "CUSTOMER"
> > WHERE "EMAIL" = "CHOOSENCUSTOMER"()]
> > at
> > org.apache.calcite.runtime.ResultSetEnumerable.enumerator(ResultSetEnumerable.java:153)
> > at
> > org.apache.calcite.linq4j.AbstractEnumerable.iterator(AbstractEnumerable.java:33)
> > at org.apache.calcite.avatica.MetaImpl.createCursor(MetaImpl.java:90)
> > at
> > org.apache.calcite.avatica.AvaticaResultSet.execute(AvaticaResultSet.java:174)
> > at
> > org.apache.calcite.jdbc.CalciteResultSet.execute(CalciteResultSet.java:67)
> > at
> > org.apache.calcite.jdbc.CalciteResultSet.execute(CalciteResultSet.java:44)
> > at
> > org.apache.calcite.avatica.AvaticaConnection$1.execute(AvaticaConnection.java:630)
> > at
> > org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:619)
> > at
> > org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:638)
> > at
> > org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:149)
> > ... 24 more
> > Caused by: java.sql.SQLSyntaxErrorException: user lacks privilege or object
> > not found: CHOOSENCUSTOMER
> > at org.hsqldb.jdbc.JDBCUtil.sqlException(Unknown Source)
> > at org.hsqldb.jdbc.JDBCUtil.sqlException(Unknown Source)
> > at org.hsqldb.jdbc.JDBCStatement.fetchResult(Unknown Source)
> > at org.hsqldb.jdbc.JDBCStatement.execute(Unknown Source)
> > at
> > org.apache.commons.dbcp.DelegatingStatement.execute(DelegatingStatement.java:264)
> > at
> > org.apache.commons.dbcp.DelegatingStatement.execute(DelegatingStatement.java:264)
> > at
> > org.apache.calcite.runtime.ResultSetEnumerable.enumerator(ResultSetEnumerable.java:143)
> > ... 33 more
> > Caused by: org.hsqldb.HsqlException: user lacks privilege or object not
> > found: CHOOSENCUSTOMER
> > at org.hsqldb.error.Error.error(Unknown Source)
> > at org.hsqldb.error.Error.error(Unknown Source)
> > at org.hsqldb.Routine.getMethods(Unknown Source)
> > at org.hsqldb.Routine.createRoutines(Unknown Source)
> > at org.hsqldb.ParserDQL.readColumnOrFunctionExpression(Unknown Source)
> > at org.hsqldb.ParserDQL.XreadSimpleValueExpressionPrimary(Unknown
> > Source)
> > at org.hsqldb.ParserDQL.XreadAllTypesValueExpressionPrimary(Unknown
> > Source)
> > at org.hsqldb.ParserDQL.XreadAllTypesPrimary(Unknown Source)
> > at org.hsqldb.ParserDQL.XreadAllTypesFactor(Unknown Source)
> > at org.hsqldb.ParserDQL.XreadAllTypesTerm(Unknown Source)
> > at org.hsqldb.ParserDQL.XreadAllTypesCommonValueExpression(Unknown
> > Source)
> > at org.hsqldb.ParserDQL.XreadRowOrCommonValueExpression(Unknown Source)
> > at org.hsqldb.ParserDQL.XreadRowValuePredicand(Unknown Source)
> > at org.hsqldb.ParserDQL.XreadPredicateRightPart(Unknown Source)
> > at org.hsqldb.ParserDQL.XreadBooleanPrimaryOrNull(Unknown Source)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2320) UDF in WHERE expression incorrectly pushed down to jdbc schema
[
https://issues.apache.org/jira/browse/CALCITE-2320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16482431#comment-16482431
]
Piotr Bojko commented on CALCITE-2320:
--
[~julianhyde] I'm in need to patch this so I will try on my own.
> UDF in WHERE expression incorrectly pushed down to jdbc schema
> --
>
> Key: CALCITE-2320
> URL: https://issues.apache.org/jira/browse/CALCITE-2320
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.16.0, 1.17.0
>Reporter: Piotr Bojko
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.17.0
>
>
> # Checks whether CHOOSENCUSTOMFUNCTION function is properly computed and not
> passed to subschema, like jdbc
> SELECT * FROM SIMPLE_CUSTOMER WHERE email = CHOOSENCUSTOMER();
> where CHOOSENCUSTOMER is UDF leads to
> {code}
> Caused by: java.lang.RuntimeException: while executing SQL [SELECT
> "FIRSTNAME", "LASTNAME", "EMAIL"
> > FROM "CUSTOMER"
> > WHERE "EMAIL" = "CHOOSENCUSTOMER"()]
> > at
> > org.apache.calcite.runtime.ResultSetEnumerable.enumerator(ResultSetEnumerable.java:153)
> > at
> > org.apache.calcite.linq4j.AbstractEnumerable.iterator(AbstractEnumerable.java:33)
> > at org.apache.calcite.avatica.MetaImpl.createCursor(MetaImpl.java:90)
> > at
> > org.apache.calcite.avatica.AvaticaResultSet.execute(AvaticaResultSet.java:174)
> > at
> > org.apache.calcite.jdbc.CalciteResultSet.execute(CalciteResultSet.java:67)
> > at
> > org.apache.calcite.jdbc.CalciteResultSet.execute(CalciteResultSet.java:44)
> > at
> > org.apache.calcite.avatica.AvaticaConnection$1.execute(AvaticaConnection.java:630)
> > at
> > org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:619)
> > at
> > org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:638)
> > at
> > org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:149)
> > ... 24 more
> > Caused by: java.sql.SQLSyntaxErrorException: user lacks privilege or object
> > not found: CHOOSENCUSTOMER
> > at org.hsqldb.jdbc.JDBCUtil.sqlException(Unknown Source)
> > at org.hsqldb.jdbc.JDBCUtil.sqlException(Unknown Source)
> > at org.hsqldb.jdbc.JDBCStatement.fetchResult(Unknown Source)
> > at org.hsqldb.jdbc.JDBCStatement.execute(Unknown Source)
> > at
> > org.apache.commons.dbcp.DelegatingStatement.execute(DelegatingStatement.java:264)
> > at
> > org.apache.commons.dbcp.DelegatingStatement.execute(DelegatingStatement.java:264)
> > at
> > org.apache.calcite.runtime.ResultSetEnumerable.enumerator(ResultSetEnumerable.java:143)
> > ... 33 more
> > Caused by: org.hsqldb.HsqlException: user lacks privilege or object not
> > found: CHOOSENCUSTOMER
> > at org.hsqldb.error.Error.error(Unknown Source)
> > at org.hsqldb.error.Error.error(Unknown Source)
> > at org.hsqldb.Routine.getMethods(Unknown Source)
> > at org.hsqldb.Routine.createRoutines(Unknown Source)
> > at org.hsqldb.ParserDQL.readColumnOrFunctionExpression(Unknown Source)
> > at org.hsqldb.ParserDQL.XreadSimpleValueExpressionPrimary(Unknown
> > Source)
> > at org.hsqldb.ParserDQL.XreadAllTypesValueExpressionPrimary(Unknown
> > Source)
> > at org.hsqldb.ParserDQL.XreadAllTypesPrimary(Unknown Source)
> > at org.hsqldb.ParserDQL.XreadAllTypesFactor(Unknown Source)
> > at org.hsqldb.ParserDQL.XreadAllTypesTerm(Unknown Source)
> > at org.hsqldb.ParserDQL.XreadAllTypesCommonValueExpression(Unknown
> > Source)
> > at org.hsqldb.ParserDQL.XreadRowOrCommonValueExpression(Unknown Source)
> > at org.hsqldb.ParserDQL.XreadRowValuePredicand(Unknown Source)
> > at org.hsqldb.ParserDQL.XreadPredicateRightPart(Unknown Source)
> > at org.hsqldb.ParserDQL.XreadBooleanPrimaryOrNull(Unknown Source)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CALCITE-2320) UDF in WHERE expression incorrectly pushed down to jdbc schema
Piotr Bojko created CALCITE-2320:
Summary: UDF in WHERE expression incorrectly pushed down to jdbc
schema
Key: CALCITE-2320
URL: https://issues.apache.org/jira/browse/CALCITE-2320
Project: Calcite
Issue Type: Bug
Affects Versions: 1.16.0, 1.17.0
Reporter: Piotr Bojko
Assignee: Julian Hyde
Fix For: 1.17.0
# Checks whether CHOOSENCUSTOMFUNCTION function is properly computed and not
passed to subschema, like jdbc
SELECT * FROM SIMPLE_CUSTOMER WHERE email = CHOOSENCUSTOMER();
where CHOOSENCUSTOMER is UDF leads to
{code}
Caused by: java.lang.RuntimeException: while executing SQL [SELECT
"FIRSTNAME", "LASTNAME", "EMAIL"
> FROM "CUSTOMER"
> WHERE "EMAIL" = "CHOOSENCUSTOMER"()]
> at
> org.apache.calcite.runtime.ResultSetEnumerable.enumerator(ResultSetEnumerable.java:153)
> at
> org.apache.calcite.linq4j.AbstractEnumerable.iterator(AbstractEnumerable.java:33)
> at org.apache.calcite.avatica.MetaImpl.createCursor(MetaImpl.java:90)
> at
> org.apache.calcite.avatica.AvaticaResultSet.execute(AvaticaResultSet.java:174)
> at
> org.apache.calcite.jdbc.CalciteResultSet.execute(CalciteResultSet.java:67)
> at
> org.apache.calcite.jdbc.CalciteResultSet.execute(CalciteResultSet.java:44)
> at
> org.apache.calcite.avatica.AvaticaConnection$1.execute(AvaticaConnection.java:630)
> at
> org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:619)
> at
> org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:638)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:149)
> ... 24 more
> Caused by: java.sql.SQLSyntaxErrorException: user lacks privilege or object
> not found: CHOOSENCUSTOMER
> at org.hsqldb.jdbc.JDBCUtil.sqlException(Unknown Source)
> at org.hsqldb.jdbc.JDBCUtil.sqlException(Unknown Source)
> at org.hsqldb.jdbc.JDBCStatement.fetchResult(Unknown Source)
> at org.hsqldb.jdbc.JDBCStatement.execute(Unknown Source)
> at
> org.apache.commons.dbcp.DelegatingStatement.execute(DelegatingStatement.java:264)
> at
> org.apache.commons.dbcp.DelegatingStatement.execute(DelegatingStatement.java:264)
> at
> org.apache.calcite.runtime.ResultSetEnumerable.enumerator(ResultSetEnumerable.java:143)
> ... 33 more
> Caused by: org.hsqldb.HsqlException: user lacks privilege or object not
> found: CHOOSENCUSTOMER
> at org.hsqldb.error.Error.error(Unknown Source)
> at org.hsqldb.error.Error.error(Unknown Source)
> at org.hsqldb.Routine.getMethods(Unknown Source)
> at org.hsqldb.Routine.createRoutines(Unknown Source)
> at org.hsqldb.ParserDQL.readColumnOrFunctionExpression(Unknown Source)
> at org.hsqldb.ParserDQL.XreadSimpleValueExpressionPrimary(Unknown
> Source)
> at org.hsqldb.ParserDQL.XreadAllTypesValueExpressionPrimary(Unknown
> Source)
> at org.hsqldb.ParserDQL.XreadAllTypesPrimary(Unknown Source)
> at org.hsqldb.ParserDQL.XreadAllTypesFactor(Unknown Source)
> at org.hsqldb.ParserDQL.XreadAllTypesTerm(Unknown Source)
> at org.hsqldb.ParserDQL.XreadAllTypesCommonValueExpression(Unknown
> Source)
> at org.hsqldb.ParserDQL.XreadRowOrCommonValueExpression(Unknown Source)
> at org.hsqldb.ParserDQL.XreadRowValuePredicand(Unknown Source)
> at org.hsqldb.ParserDQL.XreadPredicateRightPart(Unknown Source)
> at org.hsqldb.ParserDQL.XreadBooleanPrimaryOrNull(Unknown Source)
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2264) User defined function in json schema pushed to jdbc subschema.
[
https://issues.apache.org/jira/browse/CALCITE-2264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16451938#comment-16451938
]
Piotr Bojko commented on CALCITE-2264:
--
[~julianhyde] could you review the patch? :)
> User defined function in json schema pushed to jdbc subschema.
> --
>
> Key: CALCITE-2264
> URL: https://issues.apache.org/jira/browse/CALCITE-2264
> Project: Calcite
> Issue Type: Bug
>Reporter: Piotr Bojko
>Assignee: Julian Hyde
>Priority: Major
>
> Considering chinook tests, having following schema:
> {code:json}
> {
> "version": "1.0",
> "defaultSchema": "ENHANCED",
> "schemas": [
> {
> "name": "CHINOOK",
> "type": "jdbc",
> "jdbcDriver": "org.hsqldb.jdbc.JDBCDriver",
> "jdbcUrl": "jdbc:hsqldb:res:chinook",
> "jdbcUser": "sa",
> "jdbcPassword": ""
> },
> {
> "name": "ENHANCED",
> "type": "custom",
> "factory": "org.apache.calcite.schema.impl.AbstractSchema$Factory",
> "operand": {},
> "tables": [
> ...
> {
> "name" : "SIMPLE_CUSTOMER",
> "type" : "view",
> "sql" : [
> "SELECT c.firstname, c.lastname, c.email ",
> "FROM chinook.customer AS c"
> ]
> ...
> ],
> "functions": [
> {
> "name": "ASCONCATOFPARAMS",
> "className": "org.apache.calcite.chinook.StringConcatFunction"
> }
> ]
> }
> ]
> {code}
> Following query produces error:
> {code:sql}
> SELECT email, ASCONCATOFPARAMS(firstname, lastname) AS joined FROM
> SIMPLE_CUSTOMER limit 3
> {code}
> Exception:
> {code}
> > Caused by: java.lang.RuntimeException: while executing SQL [SELECT "EMAIL"
> > AS "email", "ASCONCATOFPARAMS"("FIRSTNAME", "LASTNAME") AS "joined"
> > FROM (SELECT *
> > FROM "CUSTOMER"
> > LIMIT 3) AS "t"]
> > at
> > org.apache.calcite.runtime.ResultSetEnumerable.enumerator(ResultSetEnumerable.java:153)
> > at
> > org.apache.calcite.linq4j.AbstractEnumerable.iterator(AbstractEnumerable.java:33)
> > at org.apache.calcite.avatica.MetaImpl.createCursor(MetaImpl.java:90)
> > at
> > org.apache.calcite.avatica.AvaticaResultSet.execute(AvaticaResultSet.java:174)
> > at
> > org.apache.calcite.jdbc.CalciteResultSet.execute(CalciteResultSet.java:67)
> > at
> > org.apache.calcite.jdbc.CalciteResultSet.execute(CalciteResultSet.java:44)
> > at
> > org.apache.calcite.avatica.AvaticaConnection$1.execute(AvaticaConnection.java:630)
> > at
> > org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:619)
> > at
> > org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:638)
> > at
> > org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:149)
> > ... 24 more
> > Caused by: java.sql.SQLSyntaxErrorException: user lacks privilege or object
> > not found: ASCONCATOFPARAMS
> > at org.hsqldb.jdbc.JDBCUtil.sqlException(Unknown Source)
> > at org.hsqldb.jdbc.JDBCUtil.sqlException(Unknown Source)
> > at org.hsqldb.jdbc.JDBCStatement.fetchResult(Unknown Source)
> > at org.hsqldb.jdbc.JDBCStatement.execute(Unknown Source)
> > at
> > org.apache.commons.dbcp.DelegatingStatement.execute(DelegatingStatement.java:264)
> > at
> > org.apache.commons.dbcp.DelegatingStatement.execute(DelegatingStatement.java:264)
> > at
> > org.apache.calcite.runtime.ResultSetEnumerable.enumerator(ResultSetEnumerable.java:143)
> > ... 33 more
> > Caused by: org.hsqldb.HsqlException: user lacks privilege or object not
> > found: ASCONCATOFPARAMS
> > at org.hsqldb.error.Error.error(Unknown Source)
> > at org.hsqldb.error.Error.error(Unknown Source)
> > at org.hsqldb.Routine.getMethods(Unknown Source)
> > at org.hsqldb.Routine.createRoutines(Unknown Source)
> > at org.hsqldb.ParserDQL.readColumnOrFunctionExpression(Unknown Source)
> > at org.hsqldb.ParserDQL.XreadSimpleValueExpressionPrimary(Unknown
> > Source)
> > at org.hsqldb.ParserDQL.XreadAllTypesValueExpressionPrimary(Unknown
> > Source)
> > at org.hsqldb.ParserDQL.XreadAllTypesPrimary(Unknown Source)
> > at org.hsqldb.ParserDQL.XreadAllTypesFactor(Unknown Source)
> > at org.hsqldb.ParserDQL.XreadAllTypesTerm(Unknown Source)
> > at org.hsqldb.ParserDQL.XreadAllTypesCommonValueExpression(Unknown
> > Source)
> > at org.hsqldb.ParserDQL.XreadValueExpression(Unknown Source)
> > at org.hsqldb.ParserDQL.XreadSelect(Unknown Source)
> > at org.hsqldb.ParserDQL.XreadQuerySpecification(Unknown Source)
> > at org.hsqldb.ParserDQL.XreadSimpleTable(Unknown Source)
> > at org.hsqldb.ParserDQL.XreadQueryPrimary(Unknown Source)
> > at
[jira] [Closed] (CALCITE-1993) Possible bug - NPE when using H2
[
https://issues.apache.org/jira/browse/CALCITE-1993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Piotr Bojko closed CALCITE-1993.
Resolution: Cannot Reproduce
[~julianhyde] I am closing this.
> Possible bug - NPE when using H2
>
>
> Key: CALCITE-1993
> URL: https://issues.apache.org/jira/browse/CALCITE-1993
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.13.0
> Environment: JIRA Container. Developed code is part of JIRA addon.
>Reporter: Piotr Bojko
>Assignee: Julian Hyde
>Priority: Major
>
> I've receiving NPE When using Calcite. My code is as follows
> {code:java}
> @Autowired
> public CalciteBootstrap(DatasourceProvider datasourceProvider) throws
> SQLException {
> this.datasource = datasourceProvider.fetchDatasource();
> log.debug("Datasource fetched - {}", datasource);
> this.connection = createRootSchema();
> this.schema = JdbcSchema.create(connection.getRootSchema(), "PUBLIC",
> datasource, null, null);
> connection.getRootSchema().add("jira", schema);
> connection.createStatement().executeQuery("select * from
> jira.PROJECT_KEY");
> }
> private CalciteConnection createRootSchema() {
> try {
> Class.forName("org.apache.calcite.jdbc.Driver");
> Properties info = new Properties();
> info.setProperty("lex", "JAVA");
> Connection connection = DriverManager.getConnection("jdbc:calcite:",
> info);
> CalciteConnection calciteConnection
> = connection.unwrap(CalciteConnection.class);
> return calciteConnection;
> } catch (SQLException | ClassNotFoundException ex) {
> throw new RuntimeException(ex);
> }
> }
> {code}
> And NPE:
> {noformat}
> [INFO] [talledLocalContainer] java.sql.SQLException: Error while executing
> SQL "select * from jira.PROJECT_KEY": null
> [INFO] [talledLocalContainer] at
> org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:156)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:218)
> [INFO] [talledLocalContainer] at
> com.codedoers.jira.smartql.QueryController.request(QueryController.java:23)
> ...
> [INFO] [talledLocalContainer] Caused by: java.lang.NullPointerException
> [INFO] [talledLocalContainer] at Baz.bind(Unknown Source)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.jdbc.CalcitePrepare$CalciteSignature.enumerable(CalcitePrepare.java:335)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.jdbc.CalciteConnectionImpl.enumerable(CalciteConnectionImpl.java:294)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.jdbc.CalciteMetaImpl._createIterable(CalciteMetaImpl.java:559)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.jdbc.CalciteMetaImpl.createIterable(CalciteMetaImpl.java:550)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.jdbc.CalciteResultSet.execute(CalciteResultSet.java:67)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.jdbc.CalciteResultSet.execute(CalciteResultSet.java:44)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.avatica.AvaticaConnection$1.execute(AvaticaConnection.java:630)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:607)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:638)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:149)
> [INFO] [talledLocalContainer] ... 240 more
> {noformat}
> I am developing an addon for JIRA, hence the container is JIRA. DB is H2. I
> am borrowing JIRAs datasource for Calcite.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2264) User defined function in json schema pushed to jdbc subschema.
[
https://issues.apache.org/jira/browse/CALCITE-2264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16448189#comment-16448189
]
Piotr Bojko commented on CALCITE-2264:
--
[~julianhyde] I've patched the bug here -
https://github.com/apache/calcite/pull/663
> User defined function in json schema pushed to jdbc subschema.
> --
>
> Key: CALCITE-2264
> URL: https://issues.apache.org/jira/browse/CALCITE-2264
> Project: Calcite
> Issue Type: Bug
>Reporter: Piotr Bojko
>Assignee: Julian Hyde
>Priority: Major
>
> Considering chinook tests, having following schema:
> {code:json}
> {
> "version": "1.0",
> "defaultSchema": "ENHANCED",
> "schemas": [
> {
> "name": "CHINOOK",
> "type": "jdbc",
> "jdbcDriver": "org.hsqldb.jdbc.JDBCDriver",
> "jdbcUrl": "jdbc:hsqldb:res:chinook",
> "jdbcUser": "sa",
> "jdbcPassword": ""
> },
> {
> "name": "ENHANCED",
> "type": "custom",
> "factory": "org.apache.calcite.schema.impl.AbstractSchema$Factory",
> "operand": {},
> "tables": [
> ...
> {
> "name" : "SIMPLE_CUSTOMER",
> "type" : "view",
> "sql" : [
> "SELECT c.firstname, c.lastname, c.email ",
> "FROM chinook.customer AS c"
> ]
> ...
> ],
> "functions": [
> {
> "name": "ASCONCATOFPARAMS",
> "className": "org.apache.calcite.chinook.StringConcatFunction"
> }
> ]
> }
> ]
> {code}
> Following query produces error:
> {code:sql}
> SELECT email, ASCONCATOFPARAMS(firstname, lastname) AS joined FROM
> SIMPLE_CUSTOMER limit 3
> {code}
> Exception:
> {code}
> > Caused by: java.lang.RuntimeException: while executing SQL [SELECT "EMAIL"
> > AS "email", "ASCONCATOFPARAMS"("FIRSTNAME", "LASTNAME") AS "joined"
> > FROM (SELECT *
> > FROM "CUSTOMER"
> > LIMIT 3) AS "t"]
> > at
> > org.apache.calcite.runtime.ResultSetEnumerable.enumerator(ResultSetEnumerable.java:153)
> > at
> > org.apache.calcite.linq4j.AbstractEnumerable.iterator(AbstractEnumerable.java:33)
> > at org.apache.calcite.avatica.MetaImpl.createCursor(MetaImpl.java:90)
> > at
> > org.apache.calcite.avatica.AvaticaResultSet.execute(AvaticaResultSet.java:174)
> > at
> > org.apache.calcite.jdbc.CalciteResultSet.execute(CalciteResultSet.java:67)
> > at
> > org.apache.calcite.jdbc.CalciteResultSet.execute(CalciteResultSet.java:44)
> > at
> > org.apache.calcite.avatica.AvaticaConnection$1.execute(AvaticaConnection.java:630)
> > at
> > org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:619)
> > at
> > org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:638)
> > at
> > org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:149)
> > ... 24 more
> > Caused by: java.sql.SQLSyntaxErrorException: user lacks privilege or object
> > not found: ASCONCATOFPARAMS
> > at org.hsqldb.jdbc.JDBCUtil.sqlException(Unknown Source)
> > at org.hsqldb.jdbc.JDBCUtil.sqlException(Unknown Source)
> > at org.hsqldb.jdbc.JDBCStatement.fetchResult(Unknown Source)
> > at org.hsqldb.jdbc.JDBCStatement.execute(Unknown Source)
> > at
> > org.apache.commons.dbcp.DelegatingStatement.execute(DelegatingStatement.java:264)
> > at
> > org.apache.commons.dbcp.DelegatingStatement.execute(DelegatingStatement.java:264)
> > at
> > org.apache.calcite.runtime.ResultSetEnumerable.enumerator(ResultSetEnumerable.java:143)
> > ... 33 more
> > Caused by: org.hsqldb.HsqlException: user lacks privilege or object not
> > found: ASCONCATOFPARAMS
> > at org.hsqldb.error.Error.error(Unknown Source)
> > at org.hsqldb.error.Error.error(Unknown Source)
> > at org.hsqldb.Routine.getMethods(Unknown Source)
> > at org.hsqldb.Routine.createRoutines(Unknown Source)
> > at org.hsqldb.ParserDQL.readColumnOrFunctionExpression(Unknown Source)
> > at org.hsqldb.ParserDQL.XreadSimpleValueExpressionPrimary(Unknown
> > Source)
> > at org.hsqldb.ParserDQL.XreadAllTypesValueExpressionPrimary(Unknown
> > Source)
> > at org.hsqldb.ParserDQL.XreadAllTypesPrimary(Unknown Source)
> > at org.hsqldb.ParserDQL.XreadAllTypesFactor(Unknown Source)
> > at org.hsqldb.ParserDQL.XreadAllTypesTerm(Unknown Source)
> > at org.hsqldb.ParserDQL.XreadAllTypesCommonValueExpression(Unknown
> > Source)
> > at org.hsqldb.ParserDQL.XreadValueExpression(Unknown Source)
> > at org.hsqldb.ParserDQL.XreadSelect(Unknown Source)
> > at org.hsqldb.ParserDQL.XreadQuerySpecification(Unknown Source)
> > at org.hsqldb.ParserDQL.XreadSimpleTable(Unknown Source)
> > at org.hsqldb.ParserDQL.XreadQueryPrimary(Unknown
