[jira] [Commented] (CALCITE-2188) JDBC adapter generates invalid SQL for DATE/INTERVAL arithmetic
[
https://issues.apache.org/jira/browse/CALCITE-2188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16372680#comment-16372680
]
Rahul Raj commented on CALCITE-2188:
The INTERVAL syntax is different between databases. Any thoughts on how many
databases to be supported?
> JDBC adapter generates invalid SQL for DATE/INTERVAL arithmetic
> ---
>
> Key: CALCITE-2188
> URL: https://issues.apache.org/jira/browse/CALCITE-2188
> Project: Calcite
> Issue Type: Bug
> Components: jdbc-adapter
>Reporter: Rahul Raj
>Assignee: Julian Hyde
>Priority: Major
>
> Calcite gives errors on Date interval addition/subtraction in the WHERE
> clause. For example the query {code}select * from \"sakila\".\"actor\" where
> \"last_update\" - INTERVAL '20' SECOND > TIMESTAMP '2005-10-17
> 00:00:00'{code} gives
> {noformat}
> Caused by: java.lang.UnsupportedOperationException: class
> org.apache.calcite.sql.SqlSyntax$6: SPECIAL
> at org.apache.calcite.util.Util.needToImplement(Util.java:925)
> ~[calcite-core-1.15.0-drill-r0.jar:1.15.0-drill-r0]
> at org.apache.calcite.sql.SqlSyntax$6.unparse(SqlSyntax.java:116)
> ~[calcite-core-1.15.0-drill-r0.jar:1.15.0-drill-r0]
> at org.apache.calcite.sql.SqlOperator.unparse(SqlOperator.java:332)
> ~[calcite-core-1.15.0-drill-r0.jar:1.15.0-drill-r0]
> at org.apache.calcite.sql.SqlDialect.unparseCall(SqlDialect.java:332)
> ~[calcite-core-1.15.0-drill-r0.jar:1.15.0-drill-r0]
> at
> org.apache.calcite.sql.dialect.MysqlSqlDialect.unparseCall(MysqlSqlDialect.java:154)
> ~[calcite-core-1.15.0-drill-r0.jar:1.15.0-drill-r0]
> at org.apache.calcite.sql.SqlCall.unparse(SqlCall.java:103)
> ~[calcite-core-1.15.0-drill-r0.jar:1.15.0-drill-r0]
> at org.apache.calcite.sql.SqlUtil.unparseBinarySyntax(SqlUtil.java:323)
> ~[calcite-core-1.15.0-drill-r0.jar:1.15.0-drill-r0]
> at org.apache.calcite.sql.SqlSyntax$3.unparse(SqlSyntax.java:65)
> ~[calcite-core-1.15.0-drill-r0.jar:1.15.0-drill-r0]
> at org.apache.calcite.sql.SqlOperator.unparse(SqlOperator.java:332)
> ~[calcite-core-1.15.0-drill-r0.jar:1.15.0-drill-r0]
> at org.apache.calcite.sql.SqlDialect.unparseCall(SqlDialect.java:332)
> ~[calcite-core-1.15.0-drill-r0.jar:1.15.0-drill-r0]
> at
> org.apache.calcite.sql.dialect.MysqlSqlDialect.unparseCall(MysqlSqlDialect.java:154)
> ~[calcite-core-1.15.0-drill-r0.jar:1.15.0-drill-r0]
> at org.apache.calcite.sql.SqlCall.unparse(SqlCall.java:103)
> ~[calcite-core-1.15.0-drill-r0.jar:1.15.0-drill-r0]
> at org.apache.calcite.sql.SqlNodeList.andOrList(SqlNodeList.java:142)
> ~[calcite-core-1.15.0-drill-r0.jar:1.15.0-drill-r0]
> at
> org.apache.calcite.sql.SqlOperator.unparseListClause(SqlOperator.java:347)
> ~[calcite-core-1.15.0-drill-r0.jar:1.15.0-drill-r0]
> at
> org.apache.calcite.sql.SqlSelectOperator.unparse(SqlSelectOperator.java:197)
> ~[calcite-core-1.15.0-drill-r0.jar:1.15.0-drill-r0]
> at org.apache.calcite.sql.SqlSelect.unparse(SqlSelect.java:240)
> ~[calcite-core-1.15.0-drill-r0.jar:1.15.0-drill-r0]
> at org.apache.calcite.sql.SqlNode.toSqlString(SqlNode.java:152)
> ~[calcite-core-1.15.0-drill-r0.jar:1.15.0-drill-r0]
> at org.apache.calcite.sql.SqlNode.toSqlString(SqlNode.java:158)
> ~[calcite-core-1.15.0-drill-r0.jar:1.15.0-drill-r0]
> at org.apache.drill.exec.store.jdbc.JdbcPrel.(JdbcPrel.java:65)
> ~[drill-jdbc-storage-1.13.0-SNAPSHOT.jar:1.13.0-SNAPSHOT]{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2081) NPE in join of 2 subqueries using window functions
[
https://issues.apache.org/jira/browse/CALCITE-2081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16372781#comment-16372781
]
zhen wang commented on CALCITE-2081:
https://github.com/apache/calcite/pull/634
just like Luis mentioned the issue is caused by window function variable name
collisions.
this is one possible fix, [~julianhyde] let me know your thoughts
> NPE in join of 2 subqueries using window functions
> --
>
> Key: CALCITE-2081
> URL: https://issues.apache.org/jira/browse/CALCITE-2081
> Project: Calcite
> Issue Type: Bug
>Reporter: Luis Fernando Kauer
>Assignee: Julian Hyde
>Priority: Major
>
> NPE when joining 2 subqueries that use window functions.
> Testing with a new test case in JdbcTest:
> {code}
> /** Tests for a join of subqueries using Window Functions */
> @Test public void testJoinWithWinAgg() {
> final String sql = "select a.*, b.r from\n"
> + "(select \"deptno\", first_value(\"empid\") over \n"
> + "(partition by \"deptno\" order by \"commission\") as r\n"
> + "from \"hr\".\"emps\") a\n"
> + "left join\n"
> + "(select \"deptno\", last_value(\"empid\") over \n"
> + "(partition by \"deptno\" order by \"commission\") as r\n"
> + "from \"hr\".\"emps\") b\n"
> + "on a.\"deptno\" = b.\"deptno\"";
> CalciteAssert.hr()
> .query(sql)
> .runs();
> }
> {code}
> Debugging this I found out that the NPE occurs at Expressions.declare (line
> 2937) in initializer.getType() because initializer is null. The statement is
> {code}
> int prevStart;
> {code}
> This statement does not have an initializer, but the method "declare" is
> trying to get the initializer's type, generating NPE.
> This happens when joining 2 subqueries that use window functions because they
> end up using the same variables. In BlockBuilder.append (line 124) it checks
> if the variable already exists and the problem starts there.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2002) Distinct query against in-memory values is sometimes wrong
[
https://issues.apache.org/jira/browse/CALCITE-2002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373281#comment-16373281
]
Julian Hyde commented on CALCITE-2002:
--
[~zhenw], Your PR looks great. I am testing now, and will commit shortly. I am
just confused that you mention "table function" in several places, whereas your
fix, and your test cases, deal with VALUES. I intend to remove references to
table functions before I commit. Hope that's OK.
> Distinct query against in-memory values is sometimes wrong
> --
>
> Key: CALCITE-2002
> URL: https://issues.apache.org/jira/browse/CALCITE-2002
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.14.0
>Reporter: Marc Prud'hommeaux
>Assignee: Julian Hyde
>Priority: Major
>
> The following output is clearly wrong:
> {code:title=baddistinct.sql|borderStyle=solid}
> 0: jdbc:calcite:model=inline:{"version":1.0,"> SELECT DISTINCT T.B FROM
> (VALUES (1, 'X'),(2, 'Y'),(3, 'X'),(4, 'X')) AS T(A, B);
> +---+
> | B |
> +---+
> | X |
> | Y |
> | X |
> | X |
> +---+
> 4 rows selected (0.014 seconds)
> {code}
> I'm guessing it is distinct-ing against the complete value tuple rather than
> the selected column, since the following is correct:
> {code:title=gooddistinct.sql|borderStyle=solid}
> 0: jdbc:calcite:model=inline:{"version":1.0,"> SELECT DISTINCT T.B FROM
> (VALUES (1, 'X'),(2, 'Y'),(3, 'X'),(3, 'X')) AS T(A, B);
> +---+
> | B |
> +---+
> | X |
> | Y |
> +---+
> 2 rows selected (0.013 seconds)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2081) NPE in join of 2 subqueries using window functions
[
https://issues.apache.org/jira/browse/CALCITE-2081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373345#comment-16373345
]
Julian Hyde commented on CALCITE-2081:
--
Reviewing
[PR|https://github.com/apache/calcite/pull/634/commits/71d8256573b2d57180306658aab8764636d36338].
You have the right algorithm, but you're using
{{EnumerableRelImplementor.map}} for a purpose it was not intended for. I think
you should add a {{int windowCount}} field to {{EnumerableRelImplementor}}.
Also, please move the test case from {{JdbcTest}} to {{winagg.iq}}.
> NPE in join of 2 subqueries using window functions
> --
>
> Key: CALCITE-2081
> URL: https://issues.apache.org/jira/browse/CALCITE-2081
> Project: Calcite
> Issue Type: Bug
>Reporter: Luis Fernando Kauer
>Assignee: Julian Hyde
>Priority: Major
>
> NPE when joining 2 subqueries that use window functions.
> Testing with a new test case in JdbcTest:
> {code}
> /** Tests for a join of subqueries using Window Functions */
> @Test public void testJoinWithWinAgg() {
> final String sql = "select a.*, b.r from\n"
> + "(select \"deptno\", first_value(\"empid\") over \n"
> + "(partition by \"deptno\" order by \"commission\") as r\n"
> + "from \"hr\".\"emps\") a\n"
> + "left join\n"
> + "(select \"deptno\", last_value(\"empid\") over \n"
> + "(partition by \"deptno\" order by \"commission\") as r\n"
> + "from \"hr\".\"emps\") b\n"
> + "on a.\"deptno\" = b.\"deptno\"";
> CalciteAssert.hr()
> .query(sql)
> .runs();
> }
> {code}
> Debugging this I found out that the NPE occurs at Expressions.declare (line
> 2937) in initializer.getType() because initializer is null. The statement is
> {code}
> int prevStart;
> {code}
> This statement does not have an initializer, but the method "declare" is
> trying to get the initializer's type, generating NPE.
> This happens when joining 2 subqueries that use window functions because they
> end up using the same variables. In BlockBuilder.append (line 124) it checks
> if the variable already exists and the problem starts there.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CALCITE-2189) RelMdAllPredicates fast bail out creates mismatch with RelMdTableReferences
Jesus Camacho Rodriguez created CALCITE-2189:
Summary: RelMdAllPredicates fast bail out creates mismatch with
RelMdTableReferences
Key: CALCITE-2189
URL: https://issues.apache.org/jira/browse/CALCITE-2189
Project: Calcite
Issue Type: Bug
Components: core
Reporter: Jesus Camacho Rodriguez
Assignee: Jesus Camacho Rodriguez
Fix For: 1.16.0
The idea behind the metadata providers introduced in CALCITE-1682 is that we
can identify the lineage of the expressions. If we bypass assigning a unique
identifier for the table in RelMdAllPredicates because there are no predicates
on those tables, then we will end up referencing wrong tables.
E.g.
{code}
select x.sal from
(select a.deptno, c.sal from (select * from emp limit 7) as a
cross join (select * from dept limit 1) as b
cross join (select * from emp where empno = 5 limit 2) as c) as x;
{code}
Table refs: {{[[CATALOG, SALES, DEPT].#0, [CATALOG, SALES, EMP].#0, [CATALOG,
SALES, EMP].#1]}}
Extracted predicate without fix (wrong): {{=([CATALOG, SALES, EMP].#0.$0, 5)}}
Extracted predicate with fix (correct): {{=([CATALOG, SALES, EMP].#1.$0, 5)}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (CALCITE-2189) RelMdAllPredicates fast bail out creates mismatch with RelMdTableReferences
[
https://issues.apache.org/jira/browse/CALCITE-2189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jesus Camacho Rodriguez resolved CALCITE-2189.
--
Resolution: Fixed
Fixed in http://git-wip-us.apache.org/repos/asf/calcite/commit/47c49c9 .
> RelMdAllPredicates fast bail out creates mismatch with RelMdTableReferences
> ---
>
> Key: CALCITE-2189
> URL: https://issues.apache.org/jira/browse/CALCITE-2189
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Jesus Camacho Rodriguez
>Assignee: Jesus Camacho Rodriguez
>Priority: Major
> Fix For: 1.16.0
>
>
> The idea behind the metadata providers introduced in CALCITE-1682 is that we
> can identify the lineage of the expressions. If we bypass assigning a unique
> identifier for the table in RelMdAllPredicates because there are no
> predicates on those tables, then we will end up referencing wrong tables.
> E.g.
> {code}
> select x.sal from
> (select a.deptno, c.sal from (select * from emp limit 7) as a
> cross join (select * from dept limit 1) as b
> cross join (select * from emp where empno = 5 limit 2) as c) as x;
> {code}
> Table refs: {{[[CATALOG, SALES, DEPT].#0, [CATALOG, SALES, EMP].#0, [CATALOG,
> SALES, EMP].#1]}}
> Extracted predicate without fix (wrong): {{=([CATALOG, SALES, EMP].#0.$0, 5)}}
> Extracted predicate with fix (correct): {{=([CATALOG, SALES, EMP].#1.$0, 5)}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2165) SqlCallingBinding.getOperandLiteralValue should ignore AssertionError
[
https://issues.apache.org/jira/browse/CALCITE-2165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373702#comment-16373702
]
Julian Hyde commented on CALCITE-2165:
--
That sounds reasonable, provided you are also able to remove {{catch
(AssertionError e)}}.
> SqlCallingBinding.getOperandLiteralValue should ignore AssertionError
> -
>
> Key: CALCITE-2165
> URL: https://issues.apache.org/jira/browse/CALCITE-2165
> Project: Calcite
> Issue Type: Bug
>Reporter: Dian Fu
>Assignee: Julian Hyde
>Priority: Major
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2190) Extend SubstitutionVisitor.splitFilter to cover different order of operands
[
https://issues.apache.org/jira/browse/CALCITE-2190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373832#comment-16373832
]
Jesus Camacho Rodriguez edited comment on CALCITE-2190 at 2/23/18 2:38 AM:
---
[~julianhyde], could you review https://github.com/apache/calcite/pull/635 ? It
is not a complete solution by any means, but it will help us solving the most
common cases. Thanks
was (Author: jcamachorodriguez):
[~julianhyde], could you review https://github.com/apache/calcite/pull/635 ? It
is not a complete solution by any means, but it will help us solving the most
common cases.
> Extend SubstitutionVisitor.splitFilter to cover different order of operands
> ---
>
> Key: CALCITE-2190
> URL: https://issues.apache.org/jira/browse/CALCITE-2190
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Jesus Camacho Rodriguez
>Assignee: Jesus Camacho Rodriguez
>Priority: Major
>
> {{SubstitutionVisitor.splitFilter}} does structural comparison to identify
> relevant predicates. The method could sort the operands for some expressions
> in a deterministic way to maximize possible matches.
> For instance, currently this example yields correct results:
> {code}
> condition: x = 1 or y = 2
> target:y = 2 or x = 1
> -> residue: true
> {code}
> However, the following equivalent example fails:
> {code}
> condition: x = 1 or y = 2
> target:y = 2 or 1 = x
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2190) Extend SubstitutionVisitor.splitFilter to cover different order of operands
[
https://issues.apache.org/jira/browse/CALCITE-2190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373832#comment-16373832
]
Jesus Camacho Rodriguez commented on CALCITE-2190:
--
[~julianhyde], could you review https://github.com/apache/calcite/pull/635 ? It
is not a complete solution by any means, but it will help us solving the most
common cases.
> Extend SubstitutionVisitor.splitFilter to cover different order of operands
> ---
>
> Key: CALCITE-2190
> URL: https://issues.apache.org/jira/browse/CALCITE-2190
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Jesus Camacho Rodriguez
>Assignee: Jesus Camacho Rodriguez
>Priority: Major
>
> {{SubstitutionVisitor.splitFilter}} does structural comparison to identify
> relevant predicates. The method could sort the operands for some expressions
> in a deterministic way to maximize possible matches.
> For instance, currently this example yields correct results:
> {code}
> condition: x = 1 or y = 2
> target:y = 2 or x = 1
> -> residue: true
> {code}
> However, the following equivalent example fails:
> {code}
> condition: x = 1 or y = 2
> target:y = 2 or 1 = x
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-1865) select count(1) from (select sum(1) .... without group by failed
[
https://issues.apache.org/jira/browse/CALCITE-1865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-1865:
-
Component/s: jdbc-adapter
> select count(1) from (select sum(1) without group by failed
> --
>
> Key: CALCITE-1865
> URL: https://issues.apache.org/jira/browse/CALCITE-1865
> Project: Calcite
> Issue Type: Bug
> Components: jdbc-adapter
>Reporter: zhou degao
>Assignee: Julian Hyde
>Priority: Major
>
> {noformat}
> sqlline> !connect
> jdbc:calcite:model=core/target/test-classes/test-mysql-model.j
> son admin admin;
> 0: jdbc:calcite:model=core/target/test-classe> select count(1) from (select
> sum(
> 1) from R_DATABASE ) a;
> Error: Error while executing SQL "select count(1) from (select sum(1) from
> R_DAT
> ABASE ) a": while executing SQL [SELECT COUNT(*)
> FROM (SELECT
> FROM `codedata`.`R_DATABASE`
> GROUP BY ()) AS `t`] (state=,code=0)
> java.sql.SQLException: Error while executing SQL "select count(1) from
> (select s
> um(1) from R_DATABASE ) a": while executing SQL [SELECT COUNT(*)
> FROM (SELECT
> FROM `codedata`.`R_DATABASE`
> GROUP BY ()) AS `t`]
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaSt
> atement.java:156)
> at
> org.apache.calcite.avatica.AvaticaStatement.execute(AvaticaStatement.
> java:209)
> at sqlline.Commands.execute(Commands.java:822)
> at sqlline.Commands.sql(Commands.java:732)
> at sqlline.SqlLine.dispatch(SqlLine.java:813)
> at sqlline.SqlLine.begin(SqlLine.java:686)
> at sqlline.SqlLine.start(SqlLine.java:398)
> at sqlline.SqlLine.main(SqlLine.java:291)
> Caused by: java.lang.RuntimeException: while executing SQL [SELECT COUNT(*)
> FROM (SELECT
> FROM `codedata`.`R_DATABASE`
> GROUP BY ()) AS `t`]
> at
> org.apache.calcite.runtime.ResultSetEnumerable.enumerator(ResultSetEn
> umerable.java:154)
> at
> org.apache.calcite.linq4j.AbstractEnumerable.iterator(AbstractEnumera
> ble.java:33)
> at org.apache.calcite.avatica.MetaImpl.createCursor(MetaImpl.java:81)
> at
> org.apache.calcite.avatica.AvaticaResultSet.execute(AvaticaResultSet.
> java:196)
> at
> org.apache.calcite.jdbc.CalciteResultSet.execute(CalciteResultSet.jav
> a:67)
> at
> org.apache.calcite.jdbc.CalciteResultSet.execute(CalciteResultSet.jav
> a:44)
> at
> org.apache.calcite.avatica.AvaticaConnection$1.execute(AvaticaConnect
> ion.java:607)
> at
> org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMeta
> Impl.java:600)
> at
> org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInterna
> l(AvaticaConnection.java:615)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaSt
> atement.java:148)
> ... 7 more
> Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: You
> have a
> n error in your SQL syntax; check the manual that corresponds to your MySQL
> serv
> er version for the right syntax to use near 'FROM `codedata`.`R_DATABASE`
> GROUP BY ()) AS `t`' at line 3
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown
> Source)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown
> Sou
> rce)
> at java.lang.reflect.Constructor.newInstance(Unknown Source)
> at com.mysql.jdbc.Util.handleNewInstance(Util.java:411)
> at com.mysql.jdbc.Util.getInstance(Util.java:386)
> at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1052)
> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4096)
> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4028)
> at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2490)
> at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2651)
> at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2677)
> at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2627)
> at com.mysql.jdbc.StatementImpl.execute(StatementImpl.java:841)
> at com.mysql.jdbc.StatementImpl.execute(StatementImpl.java:681)
> at
> org.apache.commons.dbcp.DelegatingStatement.execute(DelegatingStateme
> nt.java:264)
> at
> org.apache.commons.dbcp.DelegatingStatement.execute(DelegatingStateme
> nt.java:264)
> at
> org.apache.calcite.runtime.ResultSetEnumerable.enumerator(ResultSetEn
> umerable.java:144)
> ... 16 more
> 0:
[jira] [Updated] (CALCITE-2183) Implement RelSubset.copy method
[
https://issues.apache.org/jira/browse/CALCITE-2183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-2183:
-
Summary: Implement RelSubset.copy method (was: invocation of copy method
in RelSubset class)
> Implement RelSubset.copy method
> ---
>
> Key: CALCITE-2183
> URL: https://issues.apache.org/jira/browse/CALCITE-2183
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.15.0
>Reporter: Alessandro Solimando
>Assignee: Julian Hyde
>Priority: Minor
>
> Consider the following query:
> {code:sql}
> select *
> from (values (1, 'a'), (2, 'b'), (3, 'b'), (4, 'c'), (2, 'c')) as t(x, y)
> where x between 3 and 4
> {code}
> When executed, an exception is thrown (the full stack trace is at the end) in
> _copy_ method in _RelSubset_ class, as the method is not meant to be called.
>
> This happens (in this particular case) while Calcite is trying to get rid of
> unused terms (specifically, _trimUnusedFields_ method from
> _SqlToRelConverted_ class).
> This is problematic as the trace of calls is legitimate, so the method should
> be executable.
> Complete stack trace documenting the issue:
> {noformat}
> java.lang.RuntimeException: With materializationsEnabled=false, limit=0
> at
> org.apache.calcite.test.CalciteAssert.assertQuery(CalciteAssert.java:600)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1346)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1329)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returnsUnordered(CalciteAssert.java:1357)
> at
> org.apache.calcite.test.SparkAdapterTest.commonTester(SparkAdapterTest.java:93)
> at
> org.apache.calcite.test.SparkAdapterTest.testFilterBetween(SparkAdapterTest.java:460)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> Caused by: java.sql.SQLException: Error while executing SQL "select *
> from (values (1, 'a'), (2, 'b'), (3, 'b'), (4, 'c'), (2, 'c')) as t(x, y)
> where x between 3 and 4": null
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:156)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:218)
> at
> org.apache.calcite.test.CalciteAssert.assertQuery(CalciteAssert.java:568)
> ... 27 more
> Caused by: java.lang.UnsupportedOperationException
> at org.apache.calcite.plan.volcano.RelSubset.copy(RelSubset.java:149)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.trimUnusedFields(SqlToRelConverter.java:517)
> at org.apache.calcite.prepare.Prepare.trimUnusedFields(Prepare.java:391)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:304)
> at
[jira] [Resolved] (CALCITE-2185) Additional unit tests for Spark Adapter
[ https://issues.apache.org/jira/browse/CALCITE-2185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde resolved CALCITE-2185. -- Resolution: Fixed Fix Version/s: 1.16.0 Fixed in [9ee4edac|http://git-wip-us.apache.org/repos/asf/calcite/commit/9ee4edac]; thanks for the PR, [~asolimando]! > Additional unit tests for Spark Adapter > --- > > Key: CALCITE-2185 > URL: https://issues.apache.org/jira/browse/CALCITE-2185 > Project: Calcite > Issue Type: Test > Components: spark >Reporter: Alessandro Solimando >Assignee: Julian Hyde >Priority: Major > Fix For: 1.16.0 > > > Add some unit tests covering more aspects of the Spark Adapter. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CALCITE-2183) Implement RelSubset.copy method
[
https://issues.apache.org/jira/browse/CALCITE-2183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde resolved CALCITE-2183.
--
Resolution: Fixed
Fix Version/s: 1.16.0
Fixed in
[d3293319|http://git-wip-us.apache.org/repos/asf/calcite/commit/d3293319];
thanks for the PR, [~asolimando]!
> Implement RelSubset.copy method
> ---
>
> Key: CALCITE-2183
> URL: https://issues.apache.org/jira/browse/CALCITE-2183
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.15.0
>Reporter: Alessandro Solimando
>Assignee: Julian Hyde
>Priority: Minor
> Fix For: 1.16.0
>
>
> Consider the following query:
> {code:sql}
> select *
> from (values (1, 'a'), (2, 'b'), (3, 'b'), (4, 'c'), (2, 'c')) as t(x, y)
> where x between 3 and 4
> {code}
> When executed, an exception is thrown (the full stack trace is at the end) in
> _copy_ method in _RelSubset_ class, as the method is not meant to be called.
>
> This happens (in this particular case) while Calcite is trying to get rid of
> unused terms (specifically, _trimUnusedFields_ method from
> _SqlToRelConverted_ class).
> This is problematic as the trace of calls is legitimate, so the method should
> be executable.
> Complete stack trace documenting the issue:
> {noformat}
> java.lang.RuntimeException: With materializationsEnabled=false, limit=0
> at
> org.apache.calcite.test.CalciteAssert.assertQuery(CalciteAssert.java:600)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1346)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1329)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returnsUnordered(CalciteAssert.java:1357)
> at
> org.apache.calcite.test.SparkAdapterTest.commonTester(SparkAdapterTest.java:93)
> at
> org.apache.calcite.test.SparkAdapterTest.testFilterBetween(SparkAdapterTest.java:460)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> Caused by: java.sql.SQLException: Error while executing SQL "select *
> from (values (1, 'a'), (2, 'b'), (3, 'b'), (4, 'c'), (2, 'c')) as t(x, y)
> where x between 3 and 4": null
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:156)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:218)
> at
> org.apache.calcite.test.CalciteAssert.assertQuery(CalciteAssert.java:568)
> ... 27 more
> Caused by: java.lang.UnsupportedOperationException
> at org.apache.calcite.plan.volcano.RelSubset.copy(RelSubset.java:149)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.trimUnusedFields(SqlToRelConverter.java:517)
> at org.apache.calcite.prepare.Prepare.trimUnusedFields(Prepare.java:391)
> at
[jira] [Commented] (CALCITE-2015) Planner generates incompatible plan
[
https://issues.apache.org/jira/browse/CALCITE-2015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16372857#comment-16372857
]
zhen wang commented on CALCITE-2015:
interesting. with some "hint" planner knows not to strip the jdbc to enumerable
relNode, and thus actually works.
CalciteAssert.that()
.with(CalciteAssert.Config.JDBC_FOODMART)
.query("select lastName, storeName from("
+ "select c.\"lname\" as lastName, s.\"store_name\" as storeName,
s.\"coffee_bar\" as coffeeBar, sum(f"
+ ".\"unit_sales\") as unitSales\n"
+ "from "
+ "\"foodmart\".\"store\" as s "
+ "join \"foodmart\".\"sales_fact_1998\" as f "
+ "using(\"store_id\")\n"
+ "join \"foodmart\".\"customer\" as c "
+ "using(\"customer_id\")\n"
+ "where s.\"coffee_bar\"=true\n"
+ "group by c.\"lname\", s.\"store_name\", s.\"coffee_bar\")")
> Planner generates incompatible plan
> ---
>
> Key: CALCITE-2015
> URL: https://issues.apache.org/jira/browse/CALCITE-2015
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.14.0
>Reporter: Pavel Gubin
>Assignee: Julian Hyde
>Priority: Critical
> Attachments: Main.java
>
>
> Rel tree was build using RelBuilder on foodmart dataset:
> {code:java}
> RelNode rel = b.scan("foodmart", "sales_fact_1998")
> .scan("foodmart", "customer")
> .join(JoinRelType.INNER, "customer_id")
> .scan("foodmart", "store")
> .join(JoinRelType.INNER, "store_id")
> .filter(b.equals(b.field("coffee_bar"), b.literal(true)))
> .project(
> b.alias(b.field("lname"), "lastName"),
> b.alias(b.field("store_name"), "storeName"),
> b.alias(b.field("coffee_bar"), "coffeeBar"),
> b.alias(b.field("unit_sales"), "unitSales")
> )
> .aggregate(b.groupKey(b.field("lastName"),
> b.field("storeName"),
> b.field("coffeeBar")), b.sum(false, "unitSales",
> b.field("unitSales")))
> .build();
> {code}
> This tree is optimised to the following physical plan:
> {noformat}
> 22:03:26.388 [main] DEBUG org.apache.calcite.prepare.Prepare - Plan after
> physical tweaks: EnumerableAggregate(group=[{1, 6, 7}],
> unitSales=[$SUM0($4)]): rowcount = 337.5, cumulative cost = {4466.6875 rows,
> 839.0 cpu, 0.0 io}, id = 11032
> JdbcJoin(condition=[=($2, $0)], joinType=[inner]): rowcount = 3375.0,
> cumulative cost = {4087.0 rows, 839.0 cpu, 0.0 io}, id = 11030
> JdbcProject(customer_id=[$0], lname=[$2]): rowcount = 100.0, cumulative
> cost = {180.0 rows, 261.0 cpu, 0.0 io}, id = 11018
> JdbcTableScan(table=[[foodmart, customer]]): rowcount = 100.0,
> cumulative cost = {100.0 rows, 101.0 cpu, 0.0 io}, id = 1
> JdbcJoin(condition=[=($1, $3)], joinType=[inner]): rowcount = 225.0,
> cumulative cost = {532.0 rows, 578.0 cpu, 0.0 io}, id = 11028
> JdbcProject(customer_id=[$2], store_id=[$4], unit_sales=[$7]): rowcount
> = 100.0, cumulative cost = {180.0 rows, 341.0 cpu, 0.0 io}, id = 11021
> JdbcTableScan(table=[[foodmart, sales_fact_1998]]): rowcount = 100.0,
> cumulative cost = {100.0 rows, 101.0 cpu, 0.0 io}, id = 0
> JdbcProject(store_id=[$0], store_name=[$3], coffee_bar=[$19]): rowcount
> = 15.0, cumulative cost = {127.0 rows, 237.0 cpu, 0.0 io}, id = 11026
> JdbcFilter(condition=[=($19, true)]): rowcount = 15.0, cumulative
> cost = {115.0 rows, 201.0 cpu, 0.0 io}, id = 11024
> JdbcTableScan(table=[[foodmart, store]]): rowcount = 100.0,
> cumulative cost = {100.0 rows, 101.0 cpu, 0.0 io}, id = 3
> {noformat}
> Which fails on execution:
> {noformat}
> Exception in thread "main" java.lang.RuntimeException: java.sql.SQLException:
> Error while preparing statement [null]
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl$1.prepare(CalciteConnectionImpl.java:172)
> at Main.main(Main.java:68)
> Caused by: java.sql.SQLException: Error while preparing statement [null]
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.prepareStatement_(CalciteConnectionImpl.java:210)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.access$100(CalciteConnectionImpl.java:89)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl$1.prepare(CalciteConnectionImpl.java:168)
> ... 1 more
> Caused by: java.lang.ClassCastException:
> org.apache.calcite.adapter.jdbc.JdbcRules$JdbcJoin cannot be cast to
>
