[jira] [Comment Edited] (CALCITE-1062) Allowing SqlOperator to be overridden in validation
[ https://issues.apache.org/jira/browse/CALCITE-1062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15114195#comment-15114195 ] Sean Hsuan-Yi Chu edited comment on CALCITE-1062 at 1/26/16 3:37 AM: - Pull request: https://github.com/apache/calcite/pull/188 [~julianhyde] can you help review ? Thanks. was (Author: seanhychu): Pull request: https://github.com/apache/calcite/pull/187 > Allowing SqlOperator to be overridden in validation > --- > > Key: CALCITE-1062 > URL: https://issues.apache.org/jira/browse/CALCITE-1062 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Sean Hsuan-Yi Chu >Assignee: Sean Hsuan-Yi Chu > > Calcite allows function to be overridden at validation step. To be more > specific, users can provide their SqlOperatorTable, and, at validation step, > their SqlOperatorTable will be called (method: lookupOperatorOverloads) to > get a overriding function. However, so far, SqlOperator (e.g., +, - , *, > etc.) does not have this mechanism yet. > Since other systems (e.g., Apache Drill) would have more flexible type-checks > for SqlOperator's operands, this mechanism is necessary for those systems to > pass through the validation step. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CALCITE-1068) Deprecate Stacks
Julian Hyde created CALCITE-1068: Summary: Deprecate Stacks Key: CALCITE-1068 URL: https://issues.apache.org/jira/browse/CALCITE-1068 Project: Calcite Issue Type: Bug Reporter: Julian Hyde Assignee: Julian Hyde Deprecate class org.apache.calcite.util.Stacks and use java.util.ArrayDeque instead. Also remove PartiallyOrderedSet.ArrayDeque. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CALCITE-669) Move from Commons Logging to SLF4J
[ https://issues.apache.org/jira/browse/CALCITE-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15115902#comment-15115902 ] Julian Hyde edited comment on CALCITE-669 at 1/25/16 8:18 PM: -- [~elserj], Yes, commits are open following the release, and you can use your discretion as a committer. You'll probably hit a conflict in pom.xml due to CALCITE-999 https://github.com/apache/calcite/commit/4d58768d35d5accbf7330d10b91f2541b6f1ab38. was (Author: julianhyde): [~elserj], Yes, commits are open following the release, and you can use your discretion as a committer. You'll probably hit a conflict in pom.xml due to CALCITE-699 https://github.com/apache/calcite/commit/4d58768d35d5accbf7330d10b91f2541b6f1ab38. > Move from Commons Logging to SLF4J > -- > > Key: CALCITE-669 > URL: https://issues.apache.org/jira/browse/CALCITE-669 > Project: Calcite > Issue Type: Task > Components: avatica >Reporter: Nick Dimiduk >Assignee: Josh Elser >Priority: Minor > Fix For: 1.7.0 > > > As mentioned on CALCITE-641, it could be useful to adopt a logging > implementation that supports pluggable backends and has > [MDC|http://www.slf4j.org/manual.html#mdc] support. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-669) Move from Commons Logging to SLF4J
[ https://issues.apache.org/jira/browse/CALCITE-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15115642#comment-15115642 ] Josh Elser commented on CALCITE-669: [~julianhyde], am I good to merge this into master? Not sure if I missed an "all-clear" from you, but it looks like you've dotted the "i"s and crossed the "t"s. > Move from Commons Logging to SLF4J > -- > > Key: CALCITE-669 > URL: https://issues.apache.org/jira/browse/CALCITE-669 > Project: Calcite > Issue Type: Task > Components: avatica >Reporter: Nick Dimiduk >Assignee: Josh Elser >Priority: Minor > Fix For: 1.7.0 > > > As mentioned on CALCITE-641, it could be useful to adopt a logging > implementation that supports pluggable backends and has > [MDC|http://www.slf4j.org/manual.html#mdc] support. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1066) Add an extension operator table with Oracle-specific operators
[ https://issues.apache.org/jira/browse/CALCITE-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15116262#comment-15116262 ] Julian Hyde commented on CALCITE-1066: -- On my dev branch I have now implemented DECODE, NVL, LTRIM, RTRIM, GREATEST, LEAST. If folks would like to work on other functions, please pitch in! DECODE is a little inefficient because I use 'is not distinct from' for each searched value, to handle nulls correctly, and 'x is not distinct from y' translates to 'case when x is null then y is not null when y is null then x is not null else x = y end'. Maybe someone could work on simplifying that expression. > Add an extension operator table with Oracle-specific operators > -- > > Key: CALCITE-1066 > URL: https://issues.apache.org/jira/browse/CALCITE-1066 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Julian Hyde > > Add a mechanism to allow connections to use additional operator tables, the > first of which will be one with Oracle-specific functions. We don't aim to do > every function. > Important functions: > * DECODE > * NVL > * RTRIM > * LTRIM > * LPAD > * RPAD > * TO_CHAR > * TO_NUMBER > * TO_DATE > * TRUNC > * SUBSTR (different from standard SUBSTRING) > * INSTR > Easy: > * PI > * DEGREES > * RADIANS > * SIGN > * GREATEST > * LEAST -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-669) Move from Commons Logging to SLF4J
[ https://issues.apache.org/jira/browse/CALCITE-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15115902#comment-15115902 ] Julian Hyde commented on CALCITE-669: - [~elserj], Yes, commits are open following the release, and you can use your discretion as a committer. You'll probably hit a conflict in pom.xml due to CALCITE-699 https://github.com/apache/calcite/commit/4d58768d35d5accbf7330d10b91f2541b6f1ab38. > Move from Commons Logging to SLF4J > -- > > Key: CALCITE-669 > URL: https://issues.apache.org/jira/browse/CALCITE-669 > Project: Calcite > Issue Type: Task > Components: avatica >Reporter: Nick Dimiduk >Assignee: Josh Elser >Priority: Minor > Fix For: 1.7.0 > > > As mentioned on CALCITE-641, it could be useful to adopt a logging > implementation that supports pluggable backends and has > [MDC|http://www.slf4j.org/manual.html#mdc] support. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-669) Move from Commons Logging to SLF4J
[ https://issues.apache.org/jira/browse/CALCITE-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15115974#comment-15115974 ] Josh Elser commented on CALCITE-669: Ok, thanks, Julian. > Move from Commons Logging to SLF4J > -- > > Key: CALCITE-669 > URL: https://issues.apache.org/jira/browse/CALCITE-669 > Project: Calcite > Issue Type: Task > Components: avatica >Reporter: Nick Dimiduk >Assignee: Josh Elser >Priority: Minor > Fix For: 1.7.0 > > > As mentioned on CALCITE-641, it could be useful to adopt a logging > implementation that supports pluggable backends and has > [MDC|http://www.slf4j.org/manual.html#mdc] support. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CALCITE-1067) Test failures due to clashing temporary table names
Julian Hyde created CALCITE-1067:
Summary: Test failures due to clashing temporary table names
Key: CALCITE-1067
URL: https://issues.apache.org/jira/browse/CALCITE-1067
Project: Calcite
Issue Type: Bug
Reporter: Julian Hyde
Assignee: Julian Hyde
Some tests have been failing because they use the same name for their temporary
tables in hsqldb. For example,
{noformat}
Error Message
Error -1 (0) : Error while executing SQL "insert into TEST_TABLE2 values
('1735556312', '95d82c2e-49d0-4478-acb9-a7763a6234c4')": Remote driver error:
RuntimeException: java.sql.SQLDataException: data exception: string data, right
truncation; table: TEST_TABLE2 column: MSG -> SQLDataException: data
exception: string data, right truncation; table: TEST_TABLE2 column: MSG ->
HsqlException: data exception: string data, right truncation; table:
TEST_TABLE2 column: MSG -> HsqlException: data exception: string data, right
truncation
Stacktrace
org.apache.calcite.avatica.AvaticaSqlException: Error -1 (0) : Error while
executing SQL "insert into TEST_TABLE2 values ('1735556312',
'95d82c2e-49d0-4478-acb9-a7763a6234c4')": Remote driver error:
RuntimeException: java.sql.SQLDataException: data exception: string data, right
truncation; table: TEST_TABLE2 column: MSG -> SQLDataException: data
exception: string data, right truncation; table: TEST_TABLE2 column: MSG ->
HsqlException: data exception: string data, right truncation; table:
TEST_TABLE2 column: MSG -> HsqlException: data exception: string data, right
truncation
at org.apache.calcite.avatica.Helper.createException(Helper.java:53)
at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
at
org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:143)
at
org.apache.calcite.avatica.AvaticaStatement.executeLargeUpdate(AvaticaStatement.java:204)
at
org.apache.calcite.avatica.AvaticaStatement.executeUpdate(AvaticaStatement.java:199)
at
org.apache.calcite.avatica.remote.RemoteMetaTest.testRemoteStatementInsert(RemoteMetaTest.java:274)
Standard Output
jdbc:avatica:remote:url=http://localhost:55369;serialization=JSON
{noformat}
This occurs because RemoteMetaTest.testRemoteStatementInsert and
RemoteMetaTest.testRemoteStatementInsert both use a table called TEST_TABLE2.
The solution is to generate unique temporary table names; add a method {{String
AvaticaUtils.unique(String s)}} and have tests call it to make their table
names unique. They could use it for any other resources they want to be unique,
such as file names.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CALCITE-864) Correlation variable has incorrect row type if it is populated by right side of a Join
[
https://issues.apache.org/jira/browse/CALCITE-864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-864:
Summary: Correlation variable has incorrect row type if it is populated by
right side of a Join (was: Incorrect rowType of correlate variable when
correlated sub-query has its left relation as a join)
> Correlation variable has incorrect row type if it is populated by right side
> of a Join
> --
>
> Key: CALCITE-864
> URL: https://issues.apache.org/jira/browse/CALCITE-864
> Project: Calcite
> Issue Type: Bug
>Reporter: Maryann Xue
>Assignee: Julian Hyde
>
> DDL
> {code}
> create table orders (
> order_id varchar(15) not null primary key,
> customer_id\ varchar(10),
> item_id varchar(10),
> price integer,
> quantity integer,
> date timestamp,
> the_year integer);
> create table items (
> item_id varchar(10) not null primary key,
> name varchar,
> price integer,
> discount1 integer,
> discount2 integer,
> supplier_id varchar(10),
> description varchar);
> {code}
> Query:
> {code}
> select order_id
> from orders o join items i on o.item_id = i.item_id
> where quantity = (
> select max(quantity)
> from orders o2 join items i2 on o2.item_id = i2.item_id
> where i.supplier_id = i2.supplier_id
> )
> {code}
> While executing this query with option "forceDecorrelate=false", I got a
> RuntimeException:
> {code}
> java.lang.RuntimeException: java.sql.SQLException: error while executing SQL
> "select "order_id" from "Join"."OrderTable" o JOIN "Join"."ItemTable" i on
> o."item_id" = i."item_id" where quantity = (select max(quantity) from
> "Join"."OrderTable" o2 JOIN "Join"."ItemTable" i2 on o2."item_id" =
> i2."item_id" where i."supplier_id" = i2."supplier_id")":
> org.apache.phoenix.schema.TypeMismatchException: ERROR 203 (22005): Type
> mismatch. TIMESTAMP and VARCHAR for
> org.apache.phoenix.expression.CorrelateVariableFieldAccessExpression@462bd95e
> = supplier_id
> at org.apache.phoenix.calcite.CalciteIT$Sql.resultIs(CalciteIT.java:187)
> at
> org.apache.phoenix.calcite.CalciteIT.testCorrelate(CalciteIT.java:1155)
> Caused by: java.sql.SQLException: error while executing SQL "select
> "order_id" from "Join"."OrderTable" o JOIN "Join"."ItemTable" i on
> o."item_id" = i."item_id" where quantity = (select max(quantity) from
> "Join"."OrderTable" o2 JOIN "Join"."ItemTable" i2 on o2."item_id" =
> i2."item_id" where i."supplier_id" = i2."supplier_id")":
> org.apache.phoenix.schema.TypeMismatchException: ERROR 203 (22005): Type
> mismatch. TIMESTAMP and VARCHAR for
> org.apache.phoenix.expression.CorrelateVariableFieldAccessExpression@462bd95e
> = supplier_id
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:112)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:130)
> at org.apache.phoenix.calcite.CalciteIT$Sql.resultIs(CalciteIT.java:174)
> ... 28 more
> Caused by: java.lang.RuntimeException:
> org.apache.phoenix.schema.TypeMismatchException: ERROR 203 (22005): Type
> mismatch. TIMESTAMP and VARCHAR for
> org.apache.phoenix.expression.CorrelateVariableFieldAccessExpression@462bd95e
> = supplier_id
> at
> org.apache.phoenix.calcite.CalciteUtils$3.newExpression(CalciteUtils.java:145)
> at
> org.apache.phoenix.calcite.CalciteUtils.toExpression(CalciteUtils.java:807)
> at
> org.apache.phoenix.calcite.rel.PhoenixTableScan.implement(PhoenixTableScan.java:187)
> at
> org.apache.phoenix.calcite.rel.PhoenixRelImplementorImpl.visitInput(PhoenixRelImplementorImpl.java:50)
> at
> org.apache.phoenix.calcite.rel.PhoenixToClientConverter.implement(PhoenixToClientConverter.java:42)
> at
> org.apache.phoenix.calcite.rel.PhoenixRelImplementorImpl.visitInput(PhoenixRelImplementorImpl.java:50)
> at
> org.apache.phoenix.calcite.rel.PhoenixAbstractJoin.implementInput(PhoenixAbstractJoin.java:49)
> at
> org.apache.phoenix.calcite.rel.PhoenixServerJoin.implement(PhoenixServerJoin.java:113)
> at
> org.apache.phoenix.calcite.rel.PhoenixRelImplementorImpl.visitInput(PhoenixRelImplementorImpl.java:50)
> at
> org.apache.phoenix.calcite.rel.PhoenixServerAggregate.implement(PhoenixServerAggregate.java:57)
> at
> org.apache.phoenix.calcite.rel.PhoenixRelImplementorImpl.visitInput(PhoenixRelImplementorImpl.java:50)
> at
> org.apache.phoenix.calcite.rel.PhoenixCorrelate.implement(PhoenixCorrelate.java:78)
> at
> org.apache.phoenix.calcite.rel.PhoenixRelImplementorImpl.visitInput(PhoenixRelImplementorImpl.java:50)
> at
[jira] [Commented] (CALCITE-864) Correlation variable has incorrect row type if it is populated by right side of a Join
[
https://issues.apache.org/jira/browse/CALCITE-864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15116411#comment-15116411
]
Julian Hyde commented on CALCITE-864:
-
[~maryannxue], I have put a fix on julianhyde/master:
https://github.com/julianhyde/calcite/commit/d2e0b11b8e37f70d3a8d4e9570aa238a910badc7.
Can you please review?
> Correlation variable has incorrect row type if it is populated by right side
> of a Join
> --
>
> Key: CALCITE-864
> URL: https://issues.apache.org/jira/browse/CALCITE-864
> Project: Calcite
> Issue Type: Bug
>Reporter: Maryann Xue
>Assignee: Julian Hyde
>
> Incorrect rowType of correlate variable when correlated sub-query has its
> left relation as a join.
> DDL
> {code}
> create table orders (
> order_id varchar(15) not null primary key,
> customer_id\ varchar(10),
> item_id varchar(10),
> price integer,
> quantity integer,
> date timestamp,
> the_year integer);
> create table items (
> item_id varchar(10) not null primary key,
> name varchar,
> price integer,
> discount1 integer,
> discount2 integer,
> supplier_id varchar(10),
> description varchar);
> {code}
> Query:
> {code}
> select order_id
> from orders o join items i on o.item_id = i.item_id
> where quantity = (
> select max(quantity)
> from orders o2 join items i2 on o2.item_id = i2.item_id
> where i.supplier_id = i2.supplier_id
> )
> {code}
> While executing this query with option "forceDecorrelate=false", I got a
> RuntimeException:
> {code}
> java.lang.RuntimeException: java.sql.SQLException: error while executing SQL
> "select "order_id" from "Join"."OrderTable" o JOIN "Join"."ItemTable" i on
> o."item_id" = i."item_id" where quantity = (select max(quantity) from
> "Join"."OrderTable" o2 JOIN "Join"."ItemTable" i2 on o2."item_id" =
> i2."item_id" where i."supplier_id" = i2."supplier_id")":
> org.apache.phoenix.schema.TypeMismatchException: ERROR 203 (22005): Type
> mismatch. TIMESTAMP and VARCHAR for
> org.apache.phoenix.expression.CorrelateVariableFieldAccessExpression@462bd95e
> = supplier_id
> at org.apache.phoenix.calcite.CalciteIT$Sql.resultIs(CalciteIT.java:187)
> at
> org.apache.phoenix.calcite.CalciteIT.testCorrelate(CalciteIT.java:1155)
> Caused by: java.sql.SQLException: error while executing SQL "select
> "order_id" from "Join"."OrderTable" o JOIN "Join"."ItemTable" i on
> o."item_id" = i."item_id" where quantity = (select max(quantity) from
> "Join"."OrderTable" o2 JOIN "Join"."ItemTable" i2 on o2."item_id" =
> i2."item_id" where i."supplier_id" = i2."supplier_id")":
> org.apache.phoenix.schema.TypeMismatchException: ERROR 203 (22005): Type
> mismatch. TIMESTAMP and VARCHAR for
> org.apache.phoenix.expression.CorrelateVariableFieldAccessExpression@462bd95e
> = supplier_id
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:112)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:130)
> at org.apache.phoenix.calcite.CalciteIT$Sql.resultIs(CalciteIT.java:174)
> ... 28 more
> Caused by: java.lang.RuntimeException:
> org.apache.phoenix.schema.TypeMismatchException: ERROR 203 (22005): Type
> mismatch. TIMESTAMP and VARCHAR for
> org.apache.phoenix.expression.CorrelateVariableFieldAccessExpression@462bd95e
> = supplier_id
> at
> org.apache.phoenix.calcite.CalciteUtils$3.newExpression(CalciteUtils.java:145)
> at
> org.apache.phoenix.calcite.CalciteUtils.toExpression(CalciteUtils.java:807)
> at
> org.apache.phoenix.calcite.rel.PhoenixTableScan.implement(PhoenixTableScan.java:187)
> at
> org.apache.phoenix.calcite.rel.PhoenixRelImplementorImpl.visitInput(PhoenixRelImplementorImpl.java:50)
> at
> org.apache.phoenix.calcite.rel.PhoenixToClientConverter.implement(PhoenixToClientConverter.java:42)
> at
> org.apache.phoenix.calcite.rel.PhoenixRelImplementorImpl.visitInput(PhoenixRelImplementorImpl.java:50)
> at
> org.apache.phoenix.calcite.rel.PhoenixAbstractJoin.implementInput(PhoenixAbstractJoin.java:49)
> at
> org.apache.phoenix.calcite.rel.PhoenixServerJoin.implement(PhoenixServerJoin.java:113)
> at
> org.apache.phoenix.calcite.rel.PhoenixRelImplementorImpl.visitInput(PhoenixRelImplementorImpl.java:50)
> at
> org.apache.phoenix.calcite.rel.PhoenixServerAggregate.implement(PhoenixServerAggregate.java:57)
> at
> org.apache.phoenix.calcite.rel.PhoenixRelImplementorImpl.visitInput(PhoenixRelImplementorImpl.java:50)
> at
> org.apache.phoenix.calcite.rel.PhoenixCorrelate.implement(PhoenixCorrelate.java:78)
> at
>
[jira] [Commented] (CALCITE-864) Correlation variable has incorrect row type if it is populated by right side of a Join
[
https://issues.apache.org/jira/browse/CALCITE-864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15116418#comment-15116418
]
Julian Hyde commented on CALCITE-864:
-
By the way, you were exactly right about the cause. And the solution was
already there: the {{code offsetOut}} argument to
{{SqlValidatorScope.resolve}}. It just took some plumbing to connect them.
> Correlation variable has incorrect row type if it is populated by right side
> of a Join
> --
>
> Key: CALCITE-864
> URL: https://issues.apache.org/jira/browse/CALCITE-864
> Project: Calcite
> Issue Type: Bug
>Reporter: Maryann Xue
>Assignee: Julian Hyde
>
> Incorrect rowType of correlate variable when correlated sub-query has its
> left relation as a join.
> DDL
> {code}
> create table orders (
> order_id varchar(15) not null primary key,
> customer_id\ varchar(10),
> item_id varchar(10),
> price integer,
> quantity integer,
> date timestamp,
> the_year integer);
> create table items (
> item_id varchar(10) not null primary key,
> name varchar,
> price integer,
> discount1 integer,
> discount2 integer,
> supplier_id varchar(10),
> description varchar);
> {code}
> Query:
> {code}
> select order_id
> from orders o join items i on o.item_id = i.item_id
> where quantity = (
> select max(quantity)
> from orders o2 join items i2 on o2.item_id = i2.item_id
> where i.supplier_id = i2.supplier_id
> )
> {code}
> While executing this query with option "forceDecorrelate=false", I got a
> RuntimeException:
> {code}
> java.lang.RuntimeException: java.sql.SQLException: error while executing SQL
> "select "order_id" from "Join"."OrderTable" o JOIN "Join"."ItemTable" i on
> o."item_id" = i."item_id" where quantity = (select max(quantity) from
> "Join"."OrderTable" o2 JOIN "Join"."ItemTable" i2 on o2."item_id" =
> i2."item_id" where i."supplier_id" = i2."supplier_id")":
> org.apache.phoenix.schema.TypeMismatchException: ERROR 203 (22005): Type
> mismatch. TIMESTAMP and VARCHAR for
> org.apache.phoenix.expression.CorrelateVariableFieldAccessExpression@462bd95e
> = supplier_id
> at org.apache.phoenix.calcite.CalciteIT$Sql.resultIs(CalciteIT.java:187)
> at
> org.apache.phoenix.calcite.CalciteIT.testCorrelate(CalciteIT.java:1155)
> Caused by: java.sql.SQLException: error while executing SQL "select
> "order_id" from "Join"."OrderTable" o JOIN "Join"."ItemTable" i on
> o."item_id" = i."item_id" where quantity = (select max(quantity) from
> "Join"."OrderTable" o2 JOIN "Join"."ItemTable" i2 on o2."item_id" =
> i2."item_id" where i."supplier_id" = i2."supplier_id")":
> org.apache.phoenix.schema.TypeMismatchException: ERROR 203 (22005): Type
> mismatch. TIMESTAMP and VARCHAR for
> org.apache.phoenix.expression.CorrelateVariableFieldAccessExpression@462bd95e
> = supplier_id
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:112)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:130)
> at org.apache.phoenix.calcite.CalciteIT$Sql.resultIs(CalciteIT.java:174)
> ... 28 more
> Caused by: java.lang.RuntimeException:
> org.apache.phoenix.schema.TypeMismatchException: ERROR 203 (22005): Type
> mismatch. TIMESTAMP and VARCHAR for
> org.apache.phoenix.expression.CorrelateVariableFieldAccessExpression@462bd95e
> = supplier_id
> at
> org.apache.phoenix.calcite.CalciteUtils$3.newExpression(CalciteUtils.java:145)
> at
> org.apache.phoenix.calcite.CalciteUtils.toExpression(CalciteUtils.java:807)
> at
> org.apache.phoenix.calcite.rel.PhoenixTableScan.implement(PhoenixTableScan.java:187)
> at
> org.apache.phoenix.calcite.rel.PhoenixRelImplementorImpl.visitInput(PhoenixRelImplementorImpl.java:50)
> at
> org.apache.phoenix.calcite.rel.PhoenixToClientConverter.implement(PhoenixToClientConverter.java:42)
> at
> org.apache.phoenix.calcite.rel.PhoenixRelImplementorImpl.visitInput(PhoenixRelImplementorImpl.java:50)
> at
> org.apache.phoenix.calcite.rel.PhoenixAbstractJoin.implementInput(PhoenixAbstractJoin.java:49)
> at
> org.apache.phoenix.calcite.rel.PhoenixServerJoin.implement(PhoenixServerJoin.java:113)
> at
> org.apache.phoenix.calcite.rel.PhoenixRelImplementorImpl.visitInput(PhoenixRelImplementorImpl.java:50)
> at
> org.apache.phoenix.calcite.rel.PhoenixServerAggregate.implement(PhoenixServerAggregate.java:57)
> at
> org.apache.phoenix.calcite.rel.PhoenixRelImplementorImpl.visitInput(PhoenixRelImplementorImpl.java:50)
> at
>
[jira] [Resolved] (CALCITE-559) Correlated scalar subquery in WHERE gives error
[
https://issues.apache.org/jira/browse/CALCITE-559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde resolved CALCITE-559.
-
Resolution: Fixed
Fix Version/s: 1.7.0
Seems to be a duplicate of CALCITE-864.
> Correlated scalar subquery in WHERE gives error
> ---
>
> Key: CALCITE-559
> URL: https://issues.apache.org/jira/browse/CALCITE-559
> Project: Calcite
> Issue Type: Bug
>Reporter: Jinfeng Ni
>Assignee: Julian Hyde
> Fix For: 1.7.0
>
>
> Calcite will throw exception, for a query with a correlated subquery. I
> tried both sqlline and as a Junit test case inJDBCTest. Both of them hit
> exception:
> 1. sqlline
> {code}
> sqlline> !connect
> jdbc:calcite:model=core/src/test/resources/hsqldb-foodmart-lattice-model.json
> admin admin
> 0: jdbc:calcite:model=core/src/test/resources> select e."employee_id",
> d."department_id" from "foodmart"."employee" e, "foodmart"."department" d
> where e."department_id" = d."department_id" and e."salary" > (select
> avg(e2."salary") from "foodmart"."employee" e2 where e2."store_id" =
> e."store_id");
> Error: exception while executing query: while executing SQL [SELECT "$f0"
> FROM (SELECT "employee"."store_id" AS "$f0"
> FROM "foodmart"."department"
> INNER JOIN "foodmart"."employee") AS "t"
> GROUP BY "$f0"] (state=,code=0)
> {code}
> 2. As a Junit testcase:
> {code}
> @Test public void testJoinCorreScalarSubQ()
> throws ClassNotFoundException, SQLException {
> CalciteAssert.that()
> .with(CalciteAssert.Config.FOODMART_CLONE)
> .query("select e.\"employee_id\", d.\"department_id\" "
> + " from \"employee\" e, \"department\" d "
> + " where e.\"department_id\" = d.\"department_id\" and "
> + " e.\"salary\" > (select avg(e2.\"salary\") "
> + " from \"employee\" e2 "
> + " where e2.\"store_id\" = e.\"store_id\")"
> ).returnsCount(0);
> }
> {code}
> Caused by: java.lang.RuntimeException: With materializationsEnabled=false,
> limit=0
> at
> org.apache.calcite.test.CalciteAssert.assertQuery(CalciteAssert.java:461)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1159)
> ... 29 more
> Caused by: java.lang.AssertionError: Internal error: Error while applying
> rule EnumerableJoinRule, args
> [rel#160:LogicalJoin.NONE.[](left=rel#75:Subset#0.ENUMERABLE.[],right=rel#93:Subset#9.NONE.[],condition=AND(=($6,
> $17), >($11, $18)),joinType=inner)]
> at org.apache.calcite.util.Util.newInternal(Util.java:739)
> at
> org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:251)
> at ...
> ... 30 more
> Caused by: java.lang.AssertionError: Internal error: Error occurred while
> applying rule EnumerableJoinRule
> at org.apache.calcite.util.Util.newInternal(Util.java:739)
> at ... 44 more
> Caused by: java.lang.AssertionError: type mismatch:
> ref:
> DECIMAL(10, 4)
> input:
> DECIMAL(10, 4) NOT NULL
> at org.apache.calcite.plan.RelOptUtil.eq(RelOptUtil.java:1608)
> at org.apache.calcite.rex.RexChecker.visitInputRef(RexChecker.java:120)
> at .
> {code}
> The sqlline run seems to hit exception during enumerable execution, while the
> Junit run seems to hit exception in planning phase. Probably, that's because
> sqlline by default does not turn on assertion check.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
