[jira] [Commented] (CALCITE-1586) wrong rel-to-sql conversion when performing set operation more then two inputs.
[
https://issues.apache.org/jira/browse/CALCITE-1586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15831292#comment-15831292
]
Zhiqiang He commented on CALCITE-1586:
--
I'm already fix bug in SqlImplementor and changed reltosqltest to stream API.
please review it, thanks.
> wrong rel-to-sql conversion when performing set operation more then two
> inputs.
> ---
>
> Key: CALCITE-1586
> URL: https://issues.apache.org/jira/browse/CALCITE-1586
> Project: Calcite
> Issue Type: Bug
> Components: jdbc-adapter
>Affects Versions: 1.10.0
> Environment: NA
>Reporter: Zhiqiang He
>Assignee: Julian Hyde
>Priority: Critical
> Fix For: 1.12.0
>
>
> in union example, after UnionMergeRule, the union input is convert to three
> input, and rel to sql convert result is wrong.
> inputsql
> {code:sql}
> SELECT *
> FROM (SELECT \"product_id\"
> FROM \"foodmart\".\"product\"
> UNION ALL
> SELECT \"product_id\"
> FROM \"foodmart\".\"sales_fact_1997\")
> UNION ALL
> SELECT \"product_class_id\" AS \"PRODUCT_ID\"
> FROM \"foodmart\".\"product_class\"
> {code}
> output sql
> {code:sql}
> SELECT \"product_id\"
> FROM \"foodmart\".\"product\"
> UNION ALL
> SELECT \"product_id\"
> FROM \"foodmart\".\"sales_fact_199
> {code}
> the lastest union query is lost.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1592) SqlToRelConverter throws UnsupportedOperationException if query has NOT ... NOT IN
[
https://issues.apache.org/jira/browse/CALCITE-1592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15831037#comment-15831037
]
hongbin ma commented on CALCITE-1592:
-
fantastic! thank you a lot!
> SqlToRelConverter throws UnsupportedOperationException if query has NOT ...
> NOT IN
> --
>
> Key: CALCITE-1592
> URL: https://issues.apache.org/jira/browse/CALCITE-1592
> Project: Calcite
> Issue Type: Bug
>Reporter: hongbin ma
> Fix For: 1.12.0
>
>
> when we're upgrading from calcite 1.10 to 1.11. we meet found that the
> following query:
> {code:java}
> /**
>* Reads from a table.
>*/
> @Test public void testSelectx() throws SQLException {
> checkSql("model", "select * from EMPS where not (name not in ('Fred') )");
> }
> {code}
> will throw:
> {code}
> java.sql.SQLException: Error while executing SQL "select * from EMPS where
> not (name not in ('Fred') )": class org.apache.calcite.sql.SqlBasicCall:
> `EMPS`.`NAME` IN ('Fred')
> 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.CsvTest.checkSql(CsvTest.java:322)
> at org.apache.calcite.test.CsvTest.checkSql(CsvTest.java:275)
> at org.apache.calcite.test.CsvTest.testSelectx(CsvTest.java:175)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> 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:51)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:237)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
> Caused by: java.lang.UnsupportedOperationException: class
> org.apache.calcite.sql.SqlBasicCall: `EMPS`.`NAME` IN ('Fred')
> at org.apache.calcite.util.Util.needToImplement(Util.java:927)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.getValidatedNodeType(SqlValidatorImpl.java:1457)
> at
> org.apache.calcite.sql2rel.StandardConvertletTable.castToValidatedType(StandardConvertletTable.java:1304)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:4134)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertWhere(SqlToRelConverter.java:960)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:645)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:623)
> at
>
[jira] [Commented] (CALCITE-1586) wrong rel-to-sql conversion when performing set operation more then two inputs.
[
https://issues.apache.org/jira/browse/CALCITE-1586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15830980#comment-15830980
]
Julian Hyde commented on CALCITE-1586:
--
Yes. In the SqlNode AST, set-operators are binary operators; in RelNode land,
set-operators are n-ary. (Same goes for AND and OR, by the way.)
Let's not fight what's already working. Let's just fix the bug in
SqlImplementor.setOpToSql.
> wrong rel-to-sql conversion when performing set operation more then two
> inputs.
> ---
>
> Key: CALCITE-1586
> URL: https://issues.apache.org/jira/browse/CALCITE-1586
> Project: Calcite
> Issue Type: Bug
> Components: jdbc-adapter
>Affects Versions: 1.10.0
> Environment: NA
>Reporter: Zhiqiang He
>Assignee: Julian Hyde
>Priority: Critical
> Fix For: 1.12.0
>
>
> in union example, after UnionMergeRule, the union input is convert to three
> input, and rel to sql convert result is wrong.
> inputsql
> {code:sql}
> SELECT *
> FROM (SELECT \"product_id\"
> FROM \"foodmart\".\"product\"
> UNION ALL
> SELECT \"product_id\"
> FROM \"foodmart\".\"sales_fact_1997\")
> UNION ALL
> SELECT \"product_class_id\" AS \"PRODUCT_ID\"
> FROM \"foodmart\".\"product_class\"
> {code}
> output sql
> {code:sql}
> SELECT \"product_id\"
> FROM \"foodmart\".\"product\"
> UNION ALL
> SELECT \"product_id\"
> FROM \"foodmart\".\"sales_fact_199
> {code}
> the lastest union query is lost.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1586) wrong rel-to-sql conversion when performing set operation more then two inputs.
[
https://issues.apache.org/jira/browse/CALCITE-1586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15830966#comment-15830966
]
Zhiqiang He commented on CALCITE-1586:
--
It was parse (A union B) union C befor Opimizer.
but after UnionMergeRule optimizer rule executed. the rel expression was
changed to A union B union C.
> wrong rel-to-sql conversion when performing set operation more then two
> inputs.
> ---
>
> Key: CALCITE-1586
> URL: https://issues.apache.org/jira/browse/CALCITE-1586
> Project: Calcite
> Issue Type: Bug
> Components: jdbc-adapter
>Affects Versions: 1.10.0
> Environment: NA
>Reporter: Zhiqiang He
>Assignee: Julian Hyde
>Priority: Critical
> Fix For: 1.12.0
>
>
> in union example, after UnionMergeRule, the union input is convert to three
> input, and rel to sql convert result is wrong.
> inputsql
> {code:sql}
> SELECT *
> FROM (SELECT \"product_id\"
> FROM \"foodmart\".\"product\"
> UNION ALL
> SELECT \"product_id\"
> FROM \"foodmart\".\"sales_fact_1997\")
> UNION ALL
> SELECT \"product_class_id\" AS \"PRODUCT_ID\"
> FROM \"foodmart\".\"product_class\"
> {code}
> output sql
> {code:sql}
> SELECT \"product_id\"
> FROM \"foodmart\".\"product\"
> UNION ALL
> SELECT \"product_id\"
> FROM \"foodmart\".\"sales_fact_199
> {code}
> the lastest union query is lost.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1539) Enable proxy access to Avatica server for third party on behalf of end users
[ https://issues.apache.org/jira/browse/CALCITE-1539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15830904#comment-15830904 ] Jerry He commented on CALCITE-1539: --- All right. Exactly. Thanks for the good, detailed information! > Enable proxy access to Avatica server for third party on behalf of end users > > > Key: CALCITE-1539 > URL: https://issues.apache.org/jira/browse/CALCITE-1539 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Jerry He >Assignee: Josh Elser > Attachments: > 0001-CALCITE-1539-Enable-proxy-access-to-Avatica-server-f.patch > > > We want to enable proxy access to Avatica server from an end user, but the > end user comes in via a third party impersonation. For example, Knox and Hue. > The Knox server user conveys the end user to Avatica. > Similar things have been done for HBase Rest Sever HBASE-9866 and Hive Server > HIVE-5155 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CALCITE-1587) Druid adapter: topN returns approximate results
[
https://issues.apache.org/jira/browse/CALCITE-1587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15830867#comment-15830867
]
Julian Hyde edited comment on CALCITE-1587 at 1/20/17 12:09 AM:
Fixed in http://git-wip-us.apache.org/repos/asf/calcite/commit/517bf62e.
The new properties are called {{approximateDistinctCount}} and
{{approximateTopN}}; see
https://calcite.apache.org/docs/adapter.html#jdbc-connect-string-parameters
was (Author: julianhyde):
Fixed in http://git-wip-us.apache.org/repos/asf/calcite/commit/517bf62e.
> Druid adapter: topN returns approximate results
> ---
>
> Key: CALCITE-1587
> URL: https://issues.apache.org/jira/browse/CALCITE-1587
> Project: Calcite
> Issue Type: Bug
> Components: druid
>Affects Versions: 1.11.0
>Reporter: Jesus Camacho Rodriguez
>Assignee: Julian Hyde
> Fix For: 1.12.0
>
>
> Currently, we convert to _topN_ queries. However, metrics returned by Druid
> will be approximate values. Thus, probably we should not convert to Druid
> topN queries and rather always use Druid groupBy.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CALCITE-1587) Druid adapter: topN returns approximate results
[ https://issues.apache.org/jira/browse/CALCITE-1587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde resolved CALCITE-1587. -- Resolution: Fixed Fixed in http://git-wip-us.apache.org/repos/asf/calcite/commit/517bf62e. > Druid adapter: topN returns approximate results > --- > > Key: CALCITE-1587 > URL: https://issues.apache.org/jira/browse/CALCITE-1587 > Project: Calcite > Issue Type: Bug > Components: druid >Affects Versions: 1.11.0 >Reporter: Jesus Camacho Rodriguez >Assignee: Julian Hyde > Fix For: 1.12.0 > > > Currently, we convert to _topN_ queries. However, metrics returned by Druid > will be approximate values. Thus, probably we should not convert to Druid > topN queries and rather always use Druid groupBy. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CALCITE-1577) Druid adapter: Incorrect result - limit on timestamp disappears
[
https://issues.apache.org/jira/browse/CALCITE-1577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde resolved CALCITE-1577.
--
Resolution: Fixed
Fix Version/s: 1.12.0
Fixed in http://git-wip-us.apache.org/repos/asf/calcite/commit/e5c9f2ed.
> Druid adapter: Incorrect result - limit on timestamp disappears
> ---
>
> Key: CALCITE-1577
> URL: https://issues.apache.org/jira/browse/CALCITE-1577
> Project: Calcite
> Issue Type: Bug
> Components: druid
>Affects Versions: 1.11.0
>Reporter: Jesus Camacho Rodriguez
>Assignee: Jesus Camacho Rodriguez
>Priority: Critical
> Fix For: 1.12.0
>
>
> This can be observed with the following query:
> {code:sql}
> SELECT DISTINCT `__time`
> FROM store_sales_sold_time_subset
> ORDER BY `__time` ASC
> LIMIT 10;
> {code}
> Query is translated to Druid _timeseries_, but _limit_ operator disappears.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CALCITE-1580) Druid adapter: Wrong semantics for ordering within groupBy queries
[
https://issues.apache.org/jira/browse/CALCITE-1580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde resolved CALCITE-1580.
--
Resolution: Fixed
Fix Version/s: 1.12.0
Fixed in http://git-wip-us.apache.org/repos/asf/calcite/commit/a118f821.
> Druid adapter: Wrong semantics for ordering within groupBy queries
> --
>
> Key: CALCITE-1580
> URL: https://issues.apache.org/jira/browse/CALCITE-1580
> Project: Calcite
> Issue Type: Bug
> Components: druid
>Affects Versions: 1.11.0
>Reporter: Jesus Camacho Rodriguez
>Assignee: Jesus Camacho Rodriguez
>Priority: Critical
> Fix For: 1.12.0
>
>
> The scope of the ordering seems to be for _each different granularity value_
> instead of _global_.
> It can be reproduce with the following kind of query, where there exist
> multiple values for {{floor_day(`__time`)}}:
> {code:sql}
> SELECT i_brand_id, floor_day(`__time`), max(ss_quantity),
> sum(ss_wholesale_cost) as s
> FROM store_sales_sold_time_subset
> GROUP BY i_brand_id, floor_day(`__time`)
> ORDER BY i_brand_id
> LIMIT 10;
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CALCITE-1578) Druid adapter: wrong semantics of topN query limit with granularity
[
https://issues.apache.org/jira/browse/CALCITE-1578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde resolved CALCITE-1578.
--
Resolution: Fixed
Fix Version/s: 1.12.0
Fixed in http://git-wip-us.apache.org/repos/asf/calcite/commit/a118f821.
> Druid adapter: wrong semantics of topN query limit with granularity
> ---
>
> Key: CALCITE-1578
> URL: https://issues.apache.org/jira/browse/CALCITE-1578
> Project: Calcite
> Issue Type: Bug
> Components: druid
>Affects Versions: 1.11.0
>Reporter: Jesus Camacho Rodriguez
>Assignee: Julian Hyde
>Priority: Critical
> Fix For: 1.12.0
>
>
> Semantics of Druid topN query with limit and granularity is not equivalent to
> input SQL. In particular, limit is applied on each granularity value, not on
> the overall query.
> Currently, the following query will be transformed into a topN query:
> {code:sql}
> SELECT i_brand_id, floor_day(`__time`), max(ss_quantity),
> sum(ss_wholesale_cost) as s
> FROM store_sales_sold_time_subset
> GROUP BY i_brand_id, floor_day(`__time`)
> ORDER BY s DESC
> LIMIT 10;
> {code}
> Previous query outputs at most 10 rows. In turn, the equivalent SQL query for
> a Druid topN query should be expressed as:
> {code:sql}
> SELECT rs.i_brand_id, rs.d, rs.m, rs.s
> FROM (
> SELECT i_brand_id, floor_day(`__time`) as d, max(ss_quantity) as m,
> sum(ss_wholesale_cost) as s,
>ROW_NUMBER() OVER (PARTITION BY floor_day(`__time`) ORDER BY
> sum(ss_wholesale_cost) DESC ) AS rownum
> FROM store_sales_sold_time_subset
> GROUP BY i_brand_id, floor_day(`__time`)
> ) rs
> WHERE rownum <= 10;
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CALCITE-1579) Druid adapter: wrong semantics of groupBy query limit with granularity
[
https://issues.apache.org/jira/browse/CALCITE-1579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde resolved CALCITE-1579.
--
Resolution: Fixed
Fix Version/s: 1.12.0
Fixed in http://git-wip-us.apache.org/repos/asf/calcite/commit/a118f821.
> Druid adapter: wrong semantics of groupBy query limit with granularity
> --
>
> Key: CALCITE-1579
> URL: https://issues.apache.org/jira/browse/CALCITE-1579
> Project: Calcite
> Issue Type: Bug
> Components: druid
>Affects Versions: 1.11.0
>Reporter: Jesus Camacho Rodriguez
>Assignee: Julian Hyde
>Priority: Critical
> Fix For: 1.12.0
>
>
> Similar to CALCITE-1578, but for GroupBy queries. Limit is applied per
> granularity unit, not globally for the query.
> Currently, the following SQL query infers granularity 'day' for Druid
> _groupBy_ and pushes the limit, which is incorrect.
> {code:sql}
> SELECT i_brand_id, floor_day(`__time`), max(ss_quantity),
> sum(ss_wholesale_cost) as s
> FROM store_sales_sold_time_subset
> GROUP BY i_brand_id, floor_day(`__time`)
> ORDER BY s
> LIMIT 10;
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CALCITE-1594) ConventionTraitDef.getConversionData() is not thread-safe
[
https://issues.apache.org/jira/browse/CALCITE-1594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-1594:
-
Summary: ConventionTraitDef.getConversionData() is not thread-safe (was:
Test suite hangs, with many threads in ConventionTraitDef.getConversionData and
waiting to lock a WeakHashMap)
> ConventionTraitDef.getConversionData() is not thread-safe
> -
>
> Key: CALCITE-1594
> URL: https://issues.apache.org/jira/browse/CALCITE-1594
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
> Fix For: 1.12.0
>
>
> Test suite hangs with several threads in {{WeakHashMap.get}}, all called from
> {{ConventionTraitDef.getConversionData}} and using the same table.
> It is not a deadlock; all but one threads are waiting for a lock, but the
> thread that has the lock and is runnable.
> Abbreviated stack trace:
> {noformat}
> Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.72-b15 mixed mode):
> ...
> "pool-1-thread-7" #20 daemon prio=5 os_prio=0 tid=0x7f3cf4003000
> nid=0x1f12 runnable [0x7f3d3f8f4000]
>java.lang.Thread.State: RUNNABLE
> at java.util.WeakHashMap.expungeStaleEntries(WeakHashMap.java:341)
> - locked <0xa08d14a8> (a java.lang.ref.ReferenceQueue)
> at java.util.WeakHashMap.getTable(WeakHashMap.java:350)
> at java.util.WeakHashMap.get(WeakHashMap.java:397)
> at
> org.apache.calcite.plan.ConventionTraitDef.getConversionData(ConventionTraitDef.java:203)
> at
> org.apache.calcite.plan.ConventionTraitDef.convert(ConventionTraitDef.java:129)
> at
> org.apache.calcite.plan.ConventionTraitDef.convert(ConventionTraitDef.java:46)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.changeTraitsUsingConverters(VolcanoPlanner.java:1197)
> ...
> "pool-1-thread-8" #19 daemon prio=5 os_prio=0 tid=0x7f3cec001000
> nid=0x1f11 waiting for monitor entry [0x7f3d3f9f5000]
>java.lang.Thread.State: BLOCKED (on object monitor)
> at java.util.WeakHashMap.expungeStaleEntries(WeakHashMap.java:319)
> - waiting to lock <0xa08d14a8> (a java.lang.ref.ReferenceQueue)
> at java.util.WeakHashMap.getTable(WeakHashMap.java:350)
> at java.util.WeakHashMap.get(WeakHashMap.java:397)
> at
> org.apache.calcite.plan.ConventionTraitDef.getConversionData(ConventionTraitDef.java:203)
> at
> org.apache.calcite.plan.ConventionTraitDef.convert(ConventionTraitDef.java:129)
> at
> org.apache.calcite.plan.ConventionTraitDef.convert(ConventionTraitDef.java:46)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.changeTraitsUsingConverters(VolcanoPlanner.java:1197)
> ...
> "pool-1-thread-6" #17 daemon prio=5 os_prio=0 tid=0x7f3ce8001000
> nid=0x1f0f waiting for monitor entry [0x7f3d3fbf8000]
>java.lang.Thread.State: BLOCKED (on object monitor)
> at java.util.WeakHashMap.expungeStaleEntries(WeakHashMap.java:319)
> - waiting to lock <0xa08d14a8> (a java.lang.ref.ReferenceQueue)
> at java.util.WeakHashMap.getTable(WeakHashMap.java:350)
> at java.util.WeakHashMap.get(WeakHashMap.java:397)
> at
> org.apache.calcite.plan.ConventionTraitDef.getConversionData(ConventionTraitDef.java:203)
> ...
> {noformat}
> Hypothesis: we should be synchronizing access to
> {{ConventionTraitDef.plannerConversionMap}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CALCITE-1594) ConventionTraitDef.getConversionData() is not thread-safe
[
https://issues.apache.org/jira/browse/CALCITE-1594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-1594:
-
Fix Version/s: 1.12.0
> ConventionTraitDef.getConversionData() is not thread-safe
> -
>
> Key: CALCITE-1594
> URL: https://issues.apache.org/jira/browse/CALCITE-1594
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
> Fix For: 1.12.0
>
>
> Test suite hangs with several threads in {{WeakHashMap.get}}, all called from
> {{ConventionTraitDef.getConversionData}} and using the same table.
> It is not a deadlock; all but one threads are waiting for a lock, but the
> thread that has the lock and is runnable.
> Abbreviated stack trace:
> {noformat}
> Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.72-b15 mixed mode):
> ...
> "pool-1-thread-7" #20 daemon prio=5 os_prio=0 tid=0x7f3cf4003000
> nid=0x1f12 runnable [0x7f3d3f8f4000]
>java.lang.Thread.State: RUNNABLE
> at java.util.WeakHashMap.expungeStaleEntries(WeakHashMap.java:341)
> - locked <0xa08d14a8> (a java.lang.ref.ReferenceQueue)
> at java.util.WeakHashMap.getTable(WeakHashMap.java:350)
> at java.util.WeakHashMap.get(WeakHashMap.java:397)
> at
> org.apache.calcite.plan.ConventionTraitDef.getConversionData(ConventionTraitDef.java:203)
> at
> org.apache.calcite.plan.ConventionTraitDef.convert(ConventionTraitDef.java:129)
> at
> org.apache.calcite.plan.ConventionTraitDef.convert(ConventionTraitDef.java:46)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.changeTraitsUsingConverters(VolcanoPlanner.java:1197)
> ...
> "pool-1-thread-8" #19 daemon prio=5 os_prio=0 tid=0x7f3cec001000
> nid=0x1f11 waiting for monitor entry [0x7f3d3f9f5000]
>java.lang.Thread.State: BLOCKED (on object monitor)
> at java.util.WeakHashMap.expungeStaleEntries(WeakHashMap.java:319)
> - waiting to lock <0xa08d14a8> (a java.lang.ref.ReferenceQueue)
> at java.util.WeakHashMap.getTable(WeakHashMap.java:350)
> at java.util.WeakHashMap.get(WeakHashMap.java:397)
> at
> org.apache.calcite.plan.ConventionTraitDef.getConversionData(ConventionTraitDef.java:203)
> at
> org.apache.calcite.plan.ConventionTraitDef.convert(ConventionTraitDef.java:129)
> at
> org.apache.calcite.plan.ConventionTraitDef.convert(ConventionTraitDef.java:46)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.changeTraitsUsingConverters(VolcanoPlanner.java:1197)
> ...
> "pool-1-thread-6" #17 daemon prio=5 os_prio=0 tid=0x7f3ce8001000
> nid=0x1f0f waiting for monitor entry [0x7f3d3fbf8000]
>java.lang.Thread.State: BLOCKED (on object monitor)
> at java.util.WeakHashMap.expungeStaleEntries(WeakHashMap.java:319)
> - waiting to lock <0xa08d14a8> (a java.lang.ref.ReferenceQueue)
> at java.util.WeakHashMap.getTable(WeakHashMap.java:350)
> at java.util.WeakHashMap.get(WeakHashMap.java:397)
> at
> org.apache.calcite.plan.ConventionTraitDef.getConversionData(ConventionTraitDef.java:203)
> ...
> {noformat}
> Hypothesis: we should be synchronizing access to
> {{ConventionTraitDef.plannerConversionMap}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1539) Enable proxy access to Avatica server for third party on behalf of end users
[
https://issues.apache.org/jira/browse/CALCITE-1539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15830808#comment-15830808
]
Jerry He commented on CALCITE-1539:
---
I am thinking that Avatica should act as pass-thru to the Avatica
implementation (PQS). PQS needs to have all the remote ids ('knox' and 'guest')
available to it to do the verification. Is it on the same page as your
suggestion above?
> Enable proxy access to Avatica server for third party on behalf of end users
>
>
> Key: CALCITE-1539
> URL: https://issues.apache.org/jira/browse/CALCITE-1539
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Reporter: Jerry He
>Assignee: Josh Elser
> Attachments:
> 0001-CALCITE-1539-Enable-proxy-access-to-Avatica-server-f.patch
>
>
> We want to enable proxy access to Avatica server from an end user, but the
> end user comes in via a third party impersonation. For example, Knox and Hue.
> The Knox server user conveys the end user to Avatica.
> Similar things have been done for HBase Rest Sever HBASE-9866 and Hive Server
> HIVE-5155
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1539) Enable proxy access to Avatica server for third party on behalf of end users
[
https://issues.apache.org/jira/browse/CALCITE-1539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15830792#comment-15830792
]
Josh Elser commented on CALCITE-1539:
-
bq. Which layer provides the implementation, Avatica or the implementation
layer (PQS)?
Sorry I wasn't more clear. I am purely talking in terms of Avatica. We are
creating multiple ways for an Avatica implementation (PQS) to extract what the
"remote user" of a request is.
Phoenix would still be providing it's own implementation for
{{DoAsRemoteUserCallback}}.
> Enable proxy access to Avatica server for third party on behalf of end users
>
>
> Key: CALCITE-1539
> URL: https://issues.apache.org/jira/browse/CALCITE-1539
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Reporter: Jerry He
>Assignee: Josh Elser
> Attachments:
> 0001-CALCITE-1539-Enable-proxy-access-to-Avatica-server-f.patch
>
>
> We want to enable proxy access to Avatica server from an end user, but the
> end user comes in via a third party impersonation. For example, Knox and Hue.
> The Knox server user conveys the end user to Avatica.
> Similar things have been done for HBase Rest Sever HBASE-9866 and Hive Server
> HIVE-5155
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1539) Enable proxy access to Avatica server for third party on behalf of end users
[
https://issues.apache.org/jira/browse/CALCITE-1539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15830745#comment-15830745
]
Jerry He commented on CALCITE-1539:
---
bq. the implementation must verify that the caller (Knox, in your example) is
allowed to impersonate the requested user ("guest").
Yes.
bq. Then, we can provide two implementations:
Which layer provides the implementation, Avatica or the implementation layer
(PQS)?
> Enable proxy access to Avatica server for third party on behalf of end users
>
>
> Key: CALCITE-1539
> URL: https://issues.apache.org/jira/browse/CALCITE-1539
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Reporter: Jerry He
>Assignee: Josh Elser
> Attachments:
> 0001-CALCITE-1539-Enable-proxy-access-to-Avatica-server-f.patch
>
>
> We want to enable proxy access to Avatica server from an end user, but the
> end user comes in via a third party impersonation. For example, Knox and Hue.
> The Knox server user conveys the end user to Avatica.
> Similar things have been done for HBase Rest Sever HBASE-9866 and Hive Server
> HIVE-5155
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1569) Date condition can generates Integer == Integer, which is always false
[
https://issues.apache.org/jira/browse/CALCITE-1569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15830694#comment-15830694
]
Julian Hyde commented on CALCITE-1569:
--
[~zhenw], I get test failures in {{JdbcTest.testNullableTimestamp}} and
{{JdbcTest.testNullableTimestamp2}}. Can you fix them, please.
> Date condition can generates Integer == Integer, which is always false
> --
>
> Key: CALCITE-1569
> URL: https://issues.apache.org/jira/browse/CALCITE-1569
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.10.0
>Reporter: liyang
>Assignee: zhen wang
> Fix For: 1.12.0
>
>
> Run the below query on calcite 1.10.
> {code}
> select
> l.cal_dt
> , sum(left_join_gvm) as left_join_sum
> , sum(inner_join_gvm) as inner_join_sum
> from
> (
> select test_kylin_fact.cal_dt, sum(price) as left_join_gvm
> from test_kylin_fact
> group by test_kylin_fact.cal_dt
> ) l
> ,
> (
> select test_kylin_fact.cal_dt, sum(price) as inner_join_gvm
> from test_kylin_fact
> group by test_kylin_fact.cal_dt
> ) i
> where
> l.cal_dt = i.cal_dt-- this condition
> group by
> l.cal_dt
> {code}
> The where condition generates Baz code like below.
> {code}
> /* 284 */ final org.apache.calcite.linq4j.AbstractEnumerable child1 = new
> org.apache.calcite.linq4j.AbstractEnumerable(){
> /* 285 */ public org.apache.calcite.linq4j.Enumerator enumerator() {
> /* 286 */ return new org.apache.calcite.linq4j.Enumerator(){
> /* 287 */ public final org.apache.calcite.linq4j.Enumerator
> inputEnumerator = _inputEnumerable1.enumerator();
> /* 288 */ public void reset() {
> /* 289 */ inputEnumerator.reset();
> /* 290 */ }
> /* 291 */
> /* 292 */ public boolean moveNext() {
> /* 293 */ while (inputEnumerator.moveNext()) {
> /* 294 */ final Object[] current = (Object[])
> inputEnumerator.current();
> /* 295 */ final Integer inp0_ = (Integer) current[0];
> /* 296 */ final Integer inp2_ = (Integer) current[2];
> /* 297 */ if (inp0_ != null && inp2_ != null && inp0_ == inp2_)
> {
> /* 298 */ return true;
> /* 299 */ }
> /* 300 */ }
> /* 301 */ return false;
> /* 302 */ }
> /* 303 */
> /* 304 */ public void close() {
> /* 305 */ inputEnumerator.close();
> /* 306 */ }
> /* 307 */
> /* 308 */ public Object current() {
> /* 309 */ final Object[] current = (Object[])
> inputEnumerator.current();
> /* 310 */ return new Object[] {
> /* 311 */ current[0],
> /* 312 */ current[1],
> /* 313 */ current[3]};
> /* 314 */ }
> /* 315 */
> /* 316 */ };
> /* 317 */ }
> /* 318 */
> /* 319 */ };
> {code}
> The problem is {code} if (inp0_ != null && inp2_ != null && inp0_ == inp2_)
> {code} is always false, by using == to compare two Integers.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CALCITE-1594) Test suite hangs, with many threads in ConventionTraitDef.getConversionData and waiting to lock a WeakHashMap
Julian Hyde created CALCITE-1594:
Summary: Test suite hangs, with many threads in
ConventionTraitDef.getConversionData and waiting to lock a WeakHashMap
Key: CALCITE-1594
URL: https://issues.apache.org/jira/browse/CALCITE-1594
Project: Calcite
Issue Type: Bug
Reporter: Julian Hyde
Assignee: Julian Hyde
Test suite hangs with several threads in {{WeakHashMap.get}}, all called from
{{ConventionTraitDef.getConversionData}} and using the same table.
It is not a deadlock; all but one threads are waiting for a lock, but the
thread that has the lock and is runnable.
Abbreviated stack trace:
{noformat}
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.72-b15 mixed mode):
...
"pool-1-thread-7" #20 daemon prio=5 os_prio=0 tid=0x7f3cf4003000 nid=0x1f12
runnable [0x7f3d3f8f4000]
java.lang.Thread.State: RUNNABLE
at java.util.WeakHashMap.expungeStaleEntries(WeakHashMap.java:341)
- locked <0xa08d14a8> (a java.lang.ref.ReferenceQueue)
at java.util.WeakHashMap.getTable(WeakHashMap.java:350)
at java.util.WeakHashMap.get(WeakHashMap.java:397)
at
org.apache.calcite.plan.ConventionTraitDef.getConversionData(ConventionTraitDef.java:203)
at
org.apache.calcite.plan.ConventionTraitDef.convert(ConventionTraitDef.java:129)
at
org.apache.calcite.plan.ConventionTraitDef.convert(ConventionTraitDef.java:46)
at
org.apache.calcite.plan.volcano.VolcanoPlanner.changeTraitsUsingConverters(VolcanoPlanner.java:1197)
...
"pool-1-thread-8" #19 daemon prio=5 os_prio=0 tid=0x7f3cec001000 nid=0x1f11
waiting for monitor entry [0x7f3d3f9f5000]
java.lang.Thread.State: BLOCKED (on object monitor)
at java.util.WeakHashMap.expungeStaleEntries(WeakHashMap.java:319)
- waiting to lock <0xa08d14a8> (a java.lang.ref.ReferenceQueue)
at java.util.WeakHashMap.getTable(WeakHashMap.java:350)
at java.util.WeakHashMap.get(WeakHashMap.java:397)
at
org.apache.calcite.plan.ConventionTraitDef.getConversionData(ConventionTraitDef.java:203)
at
org.apache.calcite.plan.ConventionTraitDef.convert(ConventionTraitDef.java:129)
at
org.apache.calcite.plan.ConventionTraitDef.convert(ConventionTraitDef.java:46)
at
org.apache.calcite.plan.volcano.VolcanoPlanner.changeTraitsUsingConverters(VolcanoPlanner.java:1197)
...
"pool-1-thread-6" #17 daemon prio=5 os_prio=0 tid=0x7f3ce8001000 nid=0x1f0f
waiting for monitor entry [0x7f3d3fbf8000]
java.lang.Thread.State: BLOCKED (on object monitor)
at java.util.WeakHashMap.expungeStaleEntries(WeakHashMap.java:319)
- waiting to lock <0xa08d14a8> (a java.lang.ref.ReferenceQueue)
at java.util.WeakHashMap.getTable(WeakHashMap.java:350)
at java.util.WeakHashMap.get(WeakHashMap.java:397)
at
org.apache.calcite.plan.ConventionTraitDef.getConversionData(ConventionTraitDef.java:203)
...
{noformat}
Hypothesis: we should be synchronizing access to
{{ConventionTraitDef.plannerConversionMap}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1539) Enable proxy access to Avatica server for third party on behalf of end users
[
https://issues.apache.org/jira/browse/CALCITE-1539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15830599#comment-15830599
]
Josh Elser commented on CALCITE-1539:
-
bq. Sorry I made a mistake in using request.getQueryString() which makes it
confusing. I meant to get the doAs parameter in the query, it should be
something like request.getParameter("doAs").
Gotcha. That makes more sense :)
bq. say we use user guest to authenticate on Knox(Knox demo ldap), and
according to getQueryString() method in
IdentityAsserterHttpServletRequestWrapper.java in Knox, it will put doAs=guest
in the request params
As I'm re-looking at {{AvaticaServerConfiguration#doAsRemoteUser(..)}}, I'm
realizing that the javadoc should be much more clear that the implementation
*must* verify that the caller (Knox, in your example) is allowed to impersonate
the requested user ("guest"). Need to make this very clear otherwise it's a
security hole :)
bq. Knox will redirect request to PQS. In this case, the remote user is Knox
and doAsUser is guest. (correct me if I am wrong)
bq. And to keep public T doAsRemoteUser(String remoteUserName, String
remoteAddress, final Callable action) throws Exception { this method, should
we write another method in Calcite interface to cover the case of doAsUser?
This is what I was trying to point out. {{remoteUserName}} should be {{guest}}
(admittedly, the naming/javadoc aren't as clear as they could be). There is no
need to have a new parameter to this method. Your change should provide the
ability to change how Avatica extracts the {{remoteUserName}} when it invokes
the {{doAsRemtoeUser}} method.
https://github.com/apache/calcite/blob/0938c7b6d767e3242874d87a30d9112512d9243a/avatica/server/src/main/java/org/apache/calcite/avatica/server/AvaticaProtobufHandler.java#L117-L122
https://github.com/apache/calcite/blob/0938c7b6d767e3242874d87a30d9112512d9243a/avatica/server/src/main/java/org/apache/calcite/avatica/server/AvaticaJsonHandler.java#L122-L127
I would consolidate these two classes to allow for the ability to pass either
{{request.getRemoteUser()}} or a certain parameter from the HTTP request's
query string (as you described in your above example). You would add this
configuration to AvaticaServerConfiguration with a new enumeration to control
this. Something like..
{code}
interface RemoteUserExtractor extends Callable {
String extractRemoteUser(HttpServletRequest request);
}
/**
* Extract the user this request should execute as.
*/
RemoteUserExtractor getRemoteUserExtractor();
{code}
Then, we can provide two implementations:
{code}
public class HttpRequestRemoteUserExtractor implements RemoteUserExtractor {
public String extractRemoteUser(HttpServletRequest request) {
return request.getRemoteUser();
}
}
public class HttpQueryStringParameterRemoteUserExtractor implements
RemoteUserExtractor {
public String extractRemtoeUser(HttpServletRequest request) {
return request.getParameter("doAs");
}
}
{code}
Does this make sense?
> Enable proxy access to Avatica server for third party on behalf of end users
>
>
> Key: CALCITE-1539
> URL: https://issues.apache.org/jira/browse/CALCITE-1539
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Reporter: Jerry He
>Assignee: Josh Elser
> Attachments:
> 0001-CALCITE-1539-Enable-proxy-access-to-Avatica-server-f.patch
>
>
> We want to enable proxy access to Avatica server from an end user, but the
> end user comes in via a third party impersonation. For example, Knox and Hue.
> The Knox server user conveys the end user to Avatica.
> Similar things have been done for HBase Rest Sever HBASE-9866 and Hive Server
> HIVE-5155
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1593) JoinAssociateRule throws Exception in thread "main" java.lang.AssertionError: Internal error: Error while applying...
[
https://issues.apache.org/jira/browse/CALCITE-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15830591#comment-15830591
]
Julian Hyde commented on CALCITE-1593:
--
{{CyclicMetadataException}} just happens sometimes, because a {{RelSubset}} s1
can contain a relational expression r1 whose input is in {{RelSubset}} s2 that
contains a relational expression r2 whose input is in s1. That is a valid
situation, but you can see that the metadata is not well-founded. So the
framework throws {{CyclicMetadataException}} and generally it's OK to ignore
it. See for example [RelMdColumnUniqueness.areColumnsUnique(RelSubset,
RelMetadataQuery, ImmutableBitSet,
boolean)|https://github.com/apache/calcite/blob/aadc62d4c283e31b7004c98bee55c1df4128fb9e/core/src/main/java/org/apache/calcite/rel/metadata/RelMdColumnUniqueness.java#L375].
You could perhaps put a similar catch block in {{getRowCount(RelSubSet,
RelMetadataQuery)}} and I think it would do the trick.
> JoinAssociateRule throws Exception in thread "main" java.lang.AssertionError:
> Internal error: Error while applying...
> -
>
> Key: CALCITE-1593
> URL: https://issues.apache.org/jira/browse/CALCITE-1593
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.10.0
>Reporter: George Theodorakis
>Assignee: Julian Hyde
>Priority: Blocker
> Labels: beginner
>
> I have created my own operators and Convention to apply my custom cost logic.
> I have tried many rules with both Volcano and HepPlanner and everything works
> fine. When I apply LoptOptimizeRule I get the correct output. However, when I
> try to use:
> * JoinPushThroughJoinRule.LEFT,
> * JoinPushThroughJoinRule.RIGHT,
> * JoinAssociateRule.INSTANCE,
> * JoinCommuteRule.INSTANCE
> something goes wrong. I try to apply them in VolcanoPlanner in the same step
> I use my converter rules to change the initial Logical Operators to the
> custom ones.
> I declare them as:
> {code}
> static final RelOptRule SABER_JOIN_PUSH_THROUGH_JOIN_RULE_RIGHT = new
> JoinPushThroughJoinRule("JoinPushThroughJoinRule", true, SaberJoinRel.class,
> SaberRelFactories.SABER_LOGICAL_BUILDER);
>
> static final RelOptRule SABER_JOIN_PUSH_THROUGH_JOIN_RULE_LEFT = new
> JoinPushThroughJoinRule("JoinPushThroughJoinRule", false, SaberJoinRel.class,
> SaberRelFactories.SABER_LOGICAL_BUILDER);
> static final RelOptRule SABER_JOIN_COMMUTE_RULE = new
> JoinCommuteRule(SaberJoinRel.class, SaberRelFactories.SABER_LOGICAL_BUILDER,
> false);
> {code}
>
> So, when I use the four of them I get:
> {noformat}
> Exception in thread "main" java.lang.AssertionError: Internal error: Error
> while applying rule SaberProjectRule, args
> [rel#171:LogicalProject.NONE.[](input=rel#170:Subset#20.LOGICAL.[],rowtime=$8,customerid=$9,phone=$10,rowtime0=$0,orderid=$1,productid=$2,units=$3,customerid0=$4,rowtime00=$5,productid0=$6,description=$7)]
> at org.apache.calcite.util.Util.newInternal(Util.java:792)
> at
> org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:236)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:819)
> at
> org.apache.calcite.tools.Programs$RuleSetProgram.run(Programs.java:334)
> at
> org.apache.calcite.prepare.PlannerImpl.transform(PlannerImpl.java:308)
> at calcite.planner.SaberPlanner.getLogicalPlan(SaberPlanner.java:257)
> at calcite.Tester.main(Tester.java:183)
> Caused by: java.lang.AssertionError: Internal error: Error occurred while
> applying rule SaberProjectRule
> at org.apache.calcite.util.Util.newInternal(Util.java:792)
> at
> org.apache.calcite.plan.volcano.VolcanoRuleCall.transformTo(VolcanoRuleCall.java:148)
> at
> org.apache.calcite.plan.RelOptRuleCall.transformTo(RelOptRuleCall.java:225)
> at
> org.apache.calcite.rel.convert.ConverterRule.onMatch(ConverterRule.java:117)
> at
> org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:213)
> ... 5 more
> Caused by: org.apache.calcite.rel.metadata.CyclicMetadataException
> at
> org.apache.calcite.rel.metadata.CyclicMetadataException.(CyclicMetadataException.java:28)
> at GeneratedMetadataHandler_RowCount.getRowCount(Unknown Source)
> at
> org.apache.calcite.rel.metadata.RelMetadataQuery.getRowCount(RelMetadataQuery.java:201)
> at
> org.apache.calcite.rel.metadata.RelMdRowCount.getRowCount(RelMdRowCount.java:132)
> at GeneratedMetadataHandler_RowCount.getRowCount_$(Unknown Source)
> at GeneratedMetadataHandler_RowCount.getRowCount(Unknown Source)
> at
>
[jira] [Updated] (CALCITE-1593) JoinAssociateRule throws Exception in thread "main" java.lang.AssertionError: Internal error: Error while applying...
[
https://issues.apache.org/jira/browse/CALCITE-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-1593:
-
Description:
I have created my own operators and Convention to apply my custom cost logic. I
have tried many rules with both Volcano and HepPlanner and everything works
fine. When I apply LoptOptimizeRule I get the correct output. However, when I
try to use:
* JoinPushThroughJoinRule.LEFT,
* JoinPushThroughJoinRule.RIGHT,
* JoinAssociateRule.INSTANCE,
* JoinCommuteRule.INSTANCE
something goes wrong. I try to apply them in VolcanoPlanner in the same step I
use my converter rules to change the initial Logical Operators to the custom
ones.
I declare them as:
{code}
static final RelOptRule SABER_JOIN_PUSH_THROUGH_JOIN_RULE_RIGHT = new
JoinPushThroughJoinRule("JoinPushThroughJoinRule", true, SaberJoinRel.class,
SaberRelFactories.SABER_LOGICAL_BUILDER);
static final RelOptRule SABER_JOIN_PUSH_THROUGH_JOIN_RULE_LEFT = new
JoinPushThroughJoinRule("JoinPushThroughJoinRule", false, SaberJoinRel.class,
SaberRelFactories.SABER_LOGICAL_BUILDER);
static final RelOptRule SABER_JOIN_COMMUTE_RULE = new
JoinCommuteRule(SaberJoinRel.class, SaberRelFactories.SABER_LOGICAL_BUILDER,
false);
{code}
So, when I use the four of them I get:
{noformat}
Exception in thread "main" java.lang.AssertionError: Internal error: Error
while applying rule SaberProjectRule, args
[rel#171:LogicalProject.NONE.[](input=rel#170:Subset#20.LOGICAL.[],rowtime=$8,customerid=$9,phone=$10,rowtime0=$0,orderid=$1,productid=$2,units=$3,customerid0=$4,rowtime00=$5,productid0=$6,description=$7)]
at org.apache.calcite.util.Util.newInternal(Util.java:792)
at
org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:236)
at
org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:819)
at
org.apache.calcite.tools.Programs$RuleSetProgram.run(Programs.java:334)
at
org.apache.calcite.prepare.PlannerImpl.transform(PlannerImpl.java:308)
at calcite.planner.SaberPlanner.getLogicalPlan(SaberPlanner.java:257)
at calcite.Tester.main(Tester.java:183)
Caused by: java.lang.AssertionError: Internal error: Error occurred while
applying rule SaberProjectRule
at org.apache.calcite.util.Util.newInternal(Util.java:792)
at
org.apache.calcite.plan.volcano.VolcanoRuleCall.transformTo(VolcanoRuleCall.java:148)
at
org.apache.calcite.plan.RelOptRuleCall.transformTo(RelOptRuleCall.java:225)
at
org.apache.calcite.rel.convert.ConverterRule.onMatch(ConverterRule.java:117)
at
org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:213)
... 5 more
Caused by: org.apache.calcite.rel.metadata.CyclicMetadataException
at
org.apache.calcite.rel.metadata.CyclicMetadataException.(CyclicMetadataException.java:28)
at GeneratedMetadataHandler_RowCount.getRowCount(Unknown Source)
at
org.apache.calcite.rel.metadata.RelMetadataQuery.getRowCount(RelMetadataQuery.java:201)
at
org.apache.calcite.rel.metadata.RelMdRowCount.getRowCount(RelMdRowCount.java:132)
at GeneratedMetadataHandler_RowCount.getRowCount_$(Unknown Source)
at GeneratedMetadataHandler_RowCount.getRowCount(Unknown Source)
at
org.apache.calcite.rel.metadata.RelMetadataQuery.getRowCount(RelMetadataQuery.java:201)
{noformat}
If it helps, when I don't use JoinCommuteRule I don't get an exception, but I
get wrong result and when I don't use JoinAssociateRule I get:
{noformat}Exception in thread "main" java.lang.StackOverflowError
at
com.google.common.collect.ImmutableCollection.(ImmutableCollection.java:157)
at
com.google.common.collect.ImmutableList.(ImmutableList.java:313)
at
com.google.common.collect.SingletonImmutableList.(SingletonImmutableList.java:35)
at com.google.common.collect.ImmutableList.of(ImmutableList.java:76)
at org.apache.calcite.rel.SingleRel.getInputs(SingleRel.java:63)
at
org.apache.calcite.plan.volcano.RelSubset$CheapestPlanReplacer.visit(RelSubset.java:461)
{noformat}
Here is a link to the operators I created:
https://github.com/giwrgostheod/Calcite-Saber/tree/master/src/main/java/calcite/planner/common
was:
I have created my own operators and Convention to apply my custom cost logic. I
have tried many rules with both Volcano and HepPlanner and everything works
fine. When I apply LoptOptimizeRule I get the correct output. However, when I
try to use:
* JoinPushThroughJoinRule.LEFT,
* JoinPushThroughJoinRule.RIGHT,
* JoinAssociateRule.INSTANCE,
* JoinCommuteRule.INSTANCE
something goes wrong. I try to apply them in VolcanoPlanner in the same step I
use my converter rules to change the initial Logical Operators to the
[jira] [Updated] (CALCITE-1593) JoinAssociateRule throws Exception in thread "main" java.lang.AssertionError: Internal error: Error while applying...
[
https://issues.apache.org/jira/browse/CALCITE-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-1593:
-
Description:
I have created my own operators and Convention to apply my custom cost logic. I
have tried many rules with both Volcano and HepPlanner and everything works
fine. When I apply LoptOptimizeRule I get the correct output. However, when I
try to use:
* JoinPushThroughJoinRule.LEFT,
* JoinPushThroughJoinRule.RIGHT,
* JoinAssociateRule.INSTANCE,
* JoinCommuteRule.INSTANCE
something goes wrong. I try to apply them in VolcanoPlanner in the same step I
use my converter rules to change the initial Logical Operators to the custom
ones.
I declare them as:
{code}
static final RelOptRule SABER_JOIN_PUSH_THROUGH_JOIN_RULE_RIGHT = new
JoinPushThroughJoinRule("JoinPushThroughJoinRule", true, SaberJoinRel.class,
SaberRelFactories.SABER_LOGICAL_BUILDER);
static final RelOptRule SABER_JOIN_PUSH_THROUGH_JOIN_RULE_LEFT = new
JoinPushThroughJoinRule("JoinPushThroughJoinRule", false, SaberJoinRel.class,
SaberRelFactories.SABER_LOGICAL_BUILDER);
static final RelOptRule SABER_JOIN_COMMUTE_RULE = new
JoinCommuteRule(SaberJoinRel.class, SaberRelFactories.SABER_LOGICAL_BUILDER,
false);
{code}
So, when I use the four of them I get:
{noformat}
Exception in thread "main" java.lang.AssertionError: Internal error: Error
while applying rule SaberProjectRule, args
[rel#171:LogicalProject.NONE.[](input=rel#170:Subset#20.LOGICAL.[],rowtime=$8,customerid=$9,phone=$10,rowtime0=$0,orderid=$1,productid=$2,units=$3,customerid0=$4,rowtime00=$5,productid0=$6,description=$7)]
at org.apache.calcite.util.Util.newInternal(Util.java:792)
at
org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:236)
at
org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:819)
at
org.apache.calcite.tools.Programs$RuleSetProgram.run(Programs.java:334)
at
org.apache.calcite.prepare.PlannerImpl.transform(PlannerImpl.java:308)
at calcite.planner.SaberPlanner.getLogicalPlan(SaberPlanner.java:257)
at calcite.Tester.main(Tester.java:183)
Caused by: java.lang.AssertionError: Internal error: Error occurred while
applying rule SaberProjectRule
at org.apache.calcite.util.Util.newInternal(Util.java:792)
at
org.apache.calcite.plan.volcano.VolcanoRuleCall.transformTo(VolcanoRuleCall.java:148)
at
org.apache.calcite.plan.RelOptRuleCall.transformTo(RelOptRuleCall.java:225)
at
org.apache.calcite.rel.convert.ConverterRule.onMatch(ConverterRule.java:117)
at
org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:213)
... 5 more
Caused by: org.apache.calcite.rel.metadata.CyclicMetadataException
at
org.apache.calcite.rel.metadata.CyclicMetadataException.(CyclicMetadataException.java:28)
at GeneratedMetadataHandler_RowCount.getRowCount(Unknown Source)
at
org.apache.calcite.rel.metadata.RelMetadataQuery.getRowCount(RelMetadataQuery.java:201)
at
org.apache.calcite.rel.metadata.RelMdRowCount.getRowCount(RelMdRowCount.java:132)
at GeneratedMetadataHandler_RowCount.getRowCount_$(Unknown Source)
at GeneratedMetadataHandler_RowCount.getRowCount(Unknown Source)
at
org.apache.calcite.rel.metadata.RelMetadataQuery.getRowCount(RelMetadataQuery.java:201)
{noformat}
If it helps, when I don't use JoinCommuteRule I don't get an exception, but I
get wrong result and when I don't use JoinAssociateRule I get:
{noformat}Exception in thread "main" java.lang.StackOverflowError
at
com.google.common.collect.ImmutableCollection.(ImmutableCollection.java:157)
at
com.google.common.collect.ImmutableList.(ImmutableList.java:313)
at
com.google.common.collect.SingletonImmutableList.(SingletonImmutableList.java:35)
at com.google.common.collect.ImmutableList.of(ImmutableList.java:76)
at org.apache.calcite.rel.SingleRel.getInputs(SingleRel.java:63)
at
org.apache.calcite.plan.volcano.RelSubset$CheapestPlanReplacer.visit(RelSubset.java:461)
{noformat}
Here is a link to the operators I created:
https://github.com/giwrgostheod/Calcite-Saber/tree/master/src/main/java/calcite/planner/common
was:
I have created my own operators and Convention to apply my custom cost logic. I
have tried many rules with both Volcano and HepPlanner and everything works
fine. When I apply LoptOptimizeRule I get the correct output. However, when I
try to use:
JoinPushThroughJoinRule.LEFT,
JoinPushThroughJoinRule.RIGHT,
JoinAssociateRule.INSTANCE,
JoinCommuteRule.INSTANCE
something goes wrong. I try to apply them in VolcanoPlanner in the same step I
use my converter rules to change the initial Logical Operators to the custom
[jira] [Updated] (CALCITE-1569) Date condition can generates Integer == Integer, which is always false
[
https://issues.apache.org/jira/browse/CALCITE-1569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-1569:
-
Fix Version/s: 1.12.0
> Date condition can generates Integer == Integer, which is always false
> --
>
> Key: CALCITE-1569
> URL: https://issues.apache.org/jira/browse/CALCITE-1569
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.10.0
>Reporter: liyang
>Assignee: Julian Hyde
> Fix For: 1.12.0
>
>
> Run the below query on calcite 1.10.
> {code}
> select
> l.cal_dt
> , sum(left_join_gvm) as left_join_sum
> , sum(inner_join_gvm) as inner_join_sum
> from
> (
> select test_kylin_fact.cal_dt, sum(price) as left_join_gvm
> from test_kylin_fact
> group by test_kylin_fact.cal_dt
> ) l
> ,
> (
> select test_kylin_fact.cal_dt, sum(price) as inner_join_gvm
> from test_kylin_fact
> group by test_kylin_fact.cal_dt
> ) i
> where
> l.cal_dt = i.cal_dt-- this condition
> group by
> l.cal_dt
> {code}
> The where condition generates Baz code like below.
> {code}
> /* 284 */ final org.apache.calcite.linq4j.AbstractEnumerable child1 = new
> org.apache.calcite.linq4j.AbstractEnumerable(){
> /* 285 */ public org.apache.calcite.linq4j.Enumerator enumerator() {
> /* 286 */ return new org.apache.calcite.linq4j.Enumerator(){
> /* 287 */ public final org.apache.calcite.linq4j.Enumerator
> inputEnumerator = _inputEnumerable1.enumerator();
> /* 288 */ public void reset() {
> /* 289 */ inputEnumerator.reset();
> /* 290 */ }
> /* 291 */
> /* 292 */ public boolean moveNext() {
> /* 293 */ while (inputEnumerator.moveNext()) {
> /* 294 */ final Object[] current = (Object[])
> inputEnumerator.current();
> /* 295 */ final Integer inp0_ = (Integer) current[0];
> /* 296 */ final Integer inp2_ = (Integer) current[2];
> /* 297 */ if (inp0_ != null && inp2_ != null && inp0_ == inp2_)
> {
> /* 298 */ return true;
> /* 299 */ }
> /* 300 */ }
> /* 301 */ return false;
> /* 302 */ }
> /* 303 */
> /* 304 */ public void close() {
> /* 305 */ inputEnumerator.close();
> /* 306 */ }
> /* 307 */
> /* 308 */ public Object current() {
> /* 309 */ final Object[] current = (Object[])
> inputEnumerator.current();
> /* 310 */ return new Object[] {
> /* 311 */ current[0],
> /* 312 */ current[1],
> /* 313 */ current[3]};
> /* 314 */ }
> /* 315 */
> /* 316 */ };
> /* 317 */ }
> /* 318 */
> /* 319 */ };
> {code}
> The problem is {code} if (inp0_ != null && inp2_ != null && inp0_ == inp2_)
> {code} is always false, by using == to compare two Integers.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CALCITE-1569) Date condition can generates Integer == Integer, which is always false
[
https://issues.apache.org/jira/browse/CALCITE-1569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde reassigned CALCITE-1569:
Assignee: zhen wang (was: Julian Hyde)
> Date condition can generates Integer == Integer, which is always false
> --
>
> Key: CALCITE-1569
> URL: https://issues.apache.org/jira/browse/CALCITE-1569
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.10.0
>Reporter: liyang
>Assignee: zhen wang
> Fix For: 1.12.0
>
>
> Run the below query on calcite 1.10.
> {code}
> select
> l.cal_dt
> , sum(left_join_gvm) as left_join_sum
> , sum(inner_join_gvm) as inner_join_sum
> from
> (
> select test_kylin_fact.cal_dt, sum(price) as left_join_gvm
> from test_kylin_fact
> group by test_kylin_fact.cal_dt
> ) l
> ,
> (
> select test_kylin_fact.cal_dt, sum(price) as inner_join_gvm
> from test_kylin_fact
> group by test_kylin_fact.cal_dt
> ) i
> where
> l.cal_dt = i.cal_dt-- this condition
> group by
> l.cal_dt
> {code}
> The where condition generates Baz code like below.
> {code}
> /* 284 */ final org.apache.calcite.linq4j.AbstractEnumerable child1 = new
> org.apache.calcite.linq4j.AbstractEnumerable(){
> /* 285 */ public org.apache.calcite.linq4j.Enumerator enumerator() {
> /* 286 */ return new org.apache.calcite.linq4j.Enumerator(){
> /* 287 */ public final org.apache.calcite.linq4j.Enumerator
> inputEnumerator = _inputEnumerable1.enumerator();
> /* 288 */ public void reset() {
> /* 289 */ inputEnumerator.reset();
> /* 290 */ }
> /* 291 */
> /* 292 */ public boolean moveNext() {
> /* 293 */ while (inputEnumerator.moveNext()) {
> /* 294 */ final Object[] current = (Object[])
> inputEnumerator.current();
> /* 295 */ final Integer inp0_ = (Integer) current[0];
> /* 296 */ final Integer inp2_ = (Integer) current[2];
> /* 297 */ if (inp0_ != null && inp2_ != null && inp0_ == inp2_)
> {
> /* 298 */ return true;
> /* 299 */ }
> /* 300 */ }
> /* 301 */ return false;
> /* 302 */ }
> /* 303 */
> /* 304 */ public void close() {
> /* 305 */ inputEnumerator.close();
> /* 306 */ }
> /* 307 */
> /* 308 */ public Object current() {
> /* 309 */ final Object[] current = (Object[])
> inputEnumerator.current();
> /* 310 */ return new Object[] {
> /* 311 */ current[0],
> /* 312 */ current[1],
> /* 313 */ current[3]};
> /* 314 */ }
> /* 315 */
> /* 316 */ };
> /* 317 */ }
> /* 318 */
> /* 319 */ };
> {code}
> The problem is {code} if (inp0_ != null && inp2_ != null && inp0_ == inp2_)
> {code} is always false, by using == to compare two Integers.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1569) Date condition can generates Integer == Integer, which is always false
[
https://issues.apache.org/jira/browse/CALCITE-1569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15830579#comment-15830579
]
Julian Hyde commented on CALCITE-1569:
--
The fix isn't ideal. I'd rather that we convert java.sql.Date values when they
enter the system. And, if we allow java.sql.Date values then we should treat
java.util.Date, java.sql.Time and java.sql.Timestamp values similarly. But
being pragmatic, I'm going to accept the patch because it fixes cases that
didn't work previously. If we see further problems in this area, we might back
out the changes and do it properly.
[~liyang.g...@gmail.com], Can you please test your code against the patch and
confirm that it fixes the problem.
[~zhenw], Can you please submit a pull request, and post the URL here.
> Date condition can generates Integer == Integer, which is always false
> --
>
> Key: CALCITE-1569
> URL: https://issues.apache.org/jira/browse/CALCITE-1569
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.10.0
>Reporter: liyang
>Assignee: Julian Hyde
>
> Run the below query on calcite 1.10.
> {code}
> select
> l.cal_dt
> , sum(left_join_gvm) as left_join_sum
> , sum(inner_join_gvm) as inner_join_sum
> from
> (
> select test_kylin_fact.cal_dt, sum(price) as left_join_gvm
> from test_kylin_fact
> group by test_kylin_fact.cal_dt
> ) l
> ,
> (
> select test_kylin_fact.cal_dt, sum(price) as inner_join_gvm
> from test_kylin_fact
> group by test_kylin_fact.cal_dt
> ) i
> where
> l.cal_dt = i.cal_dt-- this condition
> group by
> l.cal_dt
> {code}
> The where condition generates Baz code like below.
> {code}
> /* 284 */ final org.apache.calcite.linq4j.AbstractEnumerable child1 = new
> org.apache.calcite.linq4j.AbstractEnumerable(){
> /* 285 */ public org.apache.calcite.linq4j.Enumerator enumerator() {
> /* 286 */ return new org.apache.calcite.linq4j.Enumerator(){
> /* 287 */ public final org.apache.calcite.linq4j.Enumerator
> inputEnumerator = _inputEnumerable1.enumerator();
> /* 288 */ public void reset() {
> /* 289 */ inputEnumerator.reset();
> /* 290 */ }
> /* 291 */
> /* 292 */ public boolean moveNext() {
> /* 293 */ while (inputEnumerator.moveNext()) {
> /* 294 */ final Object[] current = (Object[])
> inputEnumerator.current();
> /* 295 */ final Integer inp0_ = (Integer) current[0];
> /* 296 */ final Integer inp2_ = (Integer) current[2];
> /* 297 */ if (inp0_ != null && inp2_ != null && inp0_ == inp2_)
> {
> /* 298 */ return true;
> /* 299 */ }
> /* 300 */ }
> /* 301 */ return false;
> /* 302 */ }
> /* 303 */
> /* 304 */ public void close() {
> /* 305 */ inputEnumerator.close();
> /* 306 */ }
> /* 307 */
> /* 308 */ public Object current() {
> /* 309 */ final Object[] current = (Object[])
> inputEnumerator.current();
> /* 310 */ return new Object[] {
> /* 311 */ current[0],
> /* 312 */ current[1],
> /* 313 */ current[3]};
> /* 314 */ }
> /* 315 */
> /* 316 */ };
> /* 317 */ }
> /* 318 */
> /* 319 */ };
> {code}
> The problem is {code} if (inp0_ != null && inp2_ != null && inp0_ == inp2_)
> {code} is always false, by using == to compare two Integers.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CALCITE-1593) JoinAssociateRule throws Exception in thread "main" java.lang.AssertionError: Internal error: Error while applying...
George Theodorakis created CALCITE-1593:
---
Summary: JoinAssociateRule throws Exception in thread "main"
java.lang.AssertionError: Internal error: Error while applying...
Key: CALCITE-1593
URL: https://issues.apache.org/jira/browse/CALCITE-1593
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.10.0
Reporter: George Theodorakis
Assignee: Julian Hyde
Priority: Blocker
I have created my own operators and Convention to apply my custom cost logic. I
have tried many rules with both Volcano and HepPlanner and everything works
fine. When I apply LoptOptimizeRule I get the correct output. However, when I
try to use:
JoinPushThroughJoinRule.LEFT,
JoinPushThroughJoinRule.RIGHT,
JoinAssociateRule.INSTANCE,
JoinCommuteRule.INSTANCE
something goes wrong. I try to apply them in VolcanoPlanner in the same step I
use my converter rules to change the initial Logical Operators to the custom
ones.
I declare them as:
static final RelOptRule SABER_JOIN_PUSH_THROUGH_JOIN_RULE_RIGHT = new
JoinPushThroughJoinRule("JoinPushThroughJoinRule", true, SaberJoinRel.class,
SaberRelFactories.SABER_LOGICAL_BUILDER);
static final RelOptRule SABER_JOIN_PUSH_THROUGH_JOIN_RULE_LEFT = new
JoinPushThroughJoinRule("JoinPushThroughJoinRule", false, SaberJoinRel.class,
SaberRelFactories.SABER_LOGICAL_BUILDER);
static final RelOptRule SABER_JOIN_COMMUTE_RULE = new
JoinCommuteRule(SaberJoinRel.class, SaberRelFactories.SABER_LOGICAL_BUILDER,
false);
So, when I use the four of them I get:
Exception in thread "main" java.lang.AssertionError: Internal error: Error
while applying rule SaberProjectRule, args
[rel#171:LogicalProject.NONE.[](input=rel#170:Subset#20.LOGICAL.[],rowtime=$8,customerid=$9,phone=$10,rowtime0=$0,orderid=$1,productid=$2,units=$3,customerid0=$4,rowtime00=$5,productid0=$6,description=$7)]
at org.apache.calcite.util.Util.newInternal(Util.java:792)
at
org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:236)
at
org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:819)
at
org.apache.calcite.tools.Programs$RuleSetProgram.run(Programs.java:334)
at
org.apache.calcite.prepare.PlannerImpl.transform(PlannerImpl.java:308)
at calcite.planner.SaberPlanner.getLogicalPlan(SaberPlanner.java:257)
at calcite.Tester.main(Tester.java:183)
Caused by: java.lang.AssertionError: Internal error: Error occurred while
applying rule SaberProjectRule
at org.apache.calcite.util.Util.newInternal(Util.java:792)
at
org.apache.calcite.plan.volcano.VolcanoRuleCall.transformTo(VolcanoRuleCall.java:148)
at
org.apache.calcite.plan.RelOptRuleCall.transformTo(RelOptRuleCall.java:225)
at
org.apache.calcite.rel.convert.ConverterRule.onMatch(ConverterRule.java:117)
at
org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:213)
... 5 more
Caused by: org.apache.calcite.rel.metadata.CyclicMetadataException
at
org.apache.calcite.rel.metadata.CyclicMetadataException.(CyclicMetadataException.java:28)
at GeneratedMetadataHandler_RowCount.getRowCount(Unknown Source)
at
org.apache.calcite.rel.metadata.RelMetadataQuery.getRowCount(RelMetadataQuery.java:201)
at
org.apache.calcite.rel.metadata.RelMdRowCount.getRowCount(RelMdRowCount.java:132)
at GeneratedMetadataHandler_RowCount.getRowCount_$(Unknown Source)
at GeneratedMetadataHandler_RowCount.getRowCount(Unknown Source)
at
org.apache.calcite.rel.metadata.RelMetadataQuery.getRowCount(RelMetadataQuery.java:201)
If it helps, when I don't use JoinCommuteRule I don't get an exception, but I
get wrong result and when I don't use JoinAssociateRule I get:
Exception in thread "main" java.lang.StackOverflowError
at
com.google.common.collect.ImmutableCollection.(ImmutableCollection.java:157)
at
com.google.common.collect.ImmutableList.(ImmutableList.java:313)
at
com.google.common.collect.SingletonImmutableList.(SingletonImmutableList.java:35)
at com.google.common.collect.ImmutableList.of(ImmutableList.java:76)
at org.apache.calcite.rel.SingleRel.getInputs(SingleRel.java:63)
at
org.apache.calcite.plan.volcano.RelSubset$CheapestPlanReplacer.visit(RelSubset.java:461)
Here is a link to the operators I created:
https://github.com/giwrgostheod/Calcite-Saber/tree/master/src/main/java/calcite/planner/common
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1577) Druid adapter: Incorrect result - limit on timestamp disappears
[
https://issues.apache.org/jira/browse/CALCITE-1577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15830551#comment-15830551
]
Julian Hyde commented on CALCITE-1577:
--
Your fix looks good. After I applied on top of my fix to CALCITE-1578 et al,
the sort got pulled up out of Druid, so the explain changed, and I was able to
execute the query without Druid blowing up. So I added {{.returnsOrdered}} to
the test cases; that should give us more confidence if we need to maintain the
test in future. Will commit shortly, when the suite passes.
> Druid adapter: Incorrect result - limit on timestamp disappears
> ---
>
> Key: CALCITE-1577
> URL: https://issues.apache.org/jira/browse/CALCITE-1577
> Project: Calcite
> Issue Type: Bug
> Components: druid
>Affects Versions: 1.11.0
>Reporter: Jesus Camacho Rodriguez
>Assignee: Jesus Camacho Rodriguez
>Priority: Critical
>
> This can be observed with the following query:
> {code:sql}
> SELECT DISTINCT `__time`
> FROM store_sales_sold_time_subset
> ORDER BY `__time` ASC
> LIMIT 10;
> {code}
> Query is translated to Druid _timeseries_, but _limit_ operator disappears.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1577) Druid adapter: Incorrect result - limit on timestamp disappears
[
https://issues.apache.org/jira/browse/CALCITE-1577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15830513#comment-15830513
]
Jesus Camacho Rodriguez commented on CALCITE-1577:
--
Sure, I have created
https://github.com/apache/calcite/pull/355/commits/66339365bd40119d7bba5fa3ba42e5bbac6835d0
.
> Druid adapter: Incorrect result - limit on timestamp disappears
> ---
>
> Key: CALCITE-1577
> URL: https://issues.apache.org/jira/browse/CALCITE-1577
> Project: Calcite
> Issue Type: Bug
> Components: druid
>Affects Versions: 1.11.0
>Reporter: Jesus Camacho Rodriguez
>Assignee: Jesus Camacho Rodriguez
>Priority: Critical
>
> This can be observed with the following query:
> {code:sql}
> SELECT DISTINCT `__time`
> FROM store_sales_sold_time_subset
> ORDER BY `__time` ASC
> LIMIT 10;
> {code}
> Query is translated to Druid _timeseries_, but _limit_ operator disappears.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1586) wrong rel-to-sql conversion when performing set operation more then two inputs.
[
https://issues.apache.org/jira/browse/CALCITE-1586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15830422#comment-15830422
]
Julian Hyde commented on CALCITE-1586:
--
Thanks for the PR; I reviewed it and the logic looks good, just a couple of
"technical debt" items:
* Is it necessary to call {{SqlPrettyWriter.setNeedWhitespace}}? The writer is
supposed to add the necessary whitespace automatically. If it doesn't that is a
bug in the writer.
* Maybe {{SqlSetOperator}} should be a sub-class of {{SqlOperator}} rather than
{{SqlBinaryOperator}} at present. Does that change have a big impact?
* The {{okWithOptimizer}} method is really useful, but it would be even better
if it could be invoked as a fluid API: rather than
"sql(sql).okWithOptimizer(ruleSet, planner, expected)", people should be able
to write "sql(sql).withOptimizer(ruleSet, planner).ok(expected)".
> wrong rel-to-sql conversion when performing set operation more then two
> inputs.
> ---
>
> Key: CALCITE-1586
> URL: https://issues.apache.org/jira/browse/CALCITE-1586
> Project: Calcite
> Issue Type: Bug
> Components: jdbc-adapter
>Affects Versions: 1.10.0
> Environment: NA
>Reporter: Zhiqiang He
>Assignee: Julian Hyde
>Priority: Critical
> Fix For: 1.12.0
>
>
> in union example, after UnionMergeRule, the union input is convert to three
> input, and rel to sql convert result is wrong.
> inputsql
> {code:sql}
> SELECT *
> FROM (SELECT \"product_id\"
> FROM \"foodmart\".\"product\"
> UNION ALL
> SELECT \"product_id\"
> FROM \"foodmart\".\"sales_fact_1997\")
> UNION ALL
> SELECT \"product_class_id\" AS \"PRODUCT_ID\"
> FROM \"foodmart\".\"product_class\"
> {code}
> output sql
> {code:sql}
> SELECT \"product_id\"
> FROM \"foodmart\".\"product\"
> UNION ALL
> SELECT \"product_id\"
> FROM \"foodmart\".\"sales_fact_199
> {code}
> the lastest union query is lost.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CALCITE-1586) wrong rel-to-sql conversion when performing set operation more then two inputs.
[
https://issues.apache.org/jira/browse/CALCITE-1586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-1586:
-
Fix Version/s: 1.12.0
> wrong rel-to-sql conversion when performing set operation more then two
> inputs.
> ---
>
> Key: CALCITE-1586
> URL: https://issues.apache.org/jira/browse/CALCITE-1586
> Project: Calcite
> Issue Type: Bug
> Components: jdbc-adapter
>Affects Versions: 1.10.0
> Environment: NA
>Reporter: Zhiqiang He
>Assignee: Julian Hyde
>Priority: Critical
> Fix For: 1.12.0
>
>
> in union example, after UnionMergeRule, the union input is convert to three
> input, and rel to sql convert result is wrong.
> inputsql
> {code:sql}
> SELECT *
> FROM (SELECT \"product_id\"
> FROM \"foodmart\".\"product\"
> UNION ALL
> SELECT \"product_id\"
> FROM \"foodmart\".\"sales_fact_1997\")
> UNION ALL
> SELECT \"product_class_id\" AS \"PRODUCT_ID\"
> FROM \"foodmart\".\"product_class\"
> {code}
> output sql
> {code:sql}
> SELECT \"product_id\"
> FROM \"foodmart\".\"product\"
> UNION ALL
> SELECT \"product_id\"
> FROM \"foodmart\".\"sales_fact_199
> {code}
> the lastest union query is lost.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CALCITE-1592) SqlToRelConverter throws UnsupportedOperationException if query has NOT ... NOT IN
[
https://issues.apache.org/jira/browse/CALCITE-1592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-1592:
-
Summary: SqlToRelConverter throws UnsupportedOperationException if query
has NOT ... NOT IN (was: UnsupportedOperationException for queries with
not(not()) filters)
> SqlToRelConverter throws UnsupportedOperationException if query has NOT ...
> NOT IN
> --
>
> Key: CALCITE-1592
> URL: https://issues.apache.org/jira/browse/CALCITE-1592
> Project: Calcite
> Issue Type: Bug
>Reporter: hongbin ma
> Fix For: 1.12.0
>
>
> when we're upgrading from calcite 1.10 to 1.11. we meet found that the
> following query:
> {code:java}
> /**
>* Reads from a table.
>*/
> @Test public void testSelectx() throws SQLException {
> checkSql("model", "select * from EMPS where not (name not in ('Fred') )");
> }
> {code}
> will throw:
> {code}
> java.sql.SQLException: Error while executing SQL "select * from EMPS where
> not (name not in ('Fred') )": class org.apache.calcite.sql.SqlBasicCall:
> `EMPS`.`NAME` IN ('Fred')
> 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.CsvTest.checkSql(CsvTest.java:322)
> at org.apache.calcite.test.CsvTest.checkSql(CsvTest.java:275)
> at org.apache.calcite.test.CsvTest.testSelectx(CsvTest.java:175)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> 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:51)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:237)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
> Caused by: java.lang.UnsupportedOperationException: class
> org.apache.calcite.sql.SqlBasicCall: `EMPS`.`NAME` IN ('Fred')
> at org.apache.calcite.util.Util.needToImplement(Util.java:927)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.getValidatedNodeType(SqlValidatorImpl.java:1457)
> at
> org.apache.calcite.sql2rel.StandardConvertletTable.castToValidatedType(StandardConvertletTable.java:1304)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:4134)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertWhere(SqlToRelConverter.java:960)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:645)
> at
>
[jira] [Resolved] (CALCITE-1592) UnsupportedOperationException for queries with not(not()) filters
[
https://issues.apache.org/jira/browse/CALCITE-1592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde resolved CALCITE-1592.
--
Resolution: Fixed
Fix Version/s: 1.12.0
Fixed in http://git-wip-us.apache.org/repos/asf/calcite/commit/aadc62d4.
> UnsupportedOperationException for queries with not(not()) filters
> -
>
> Key: CALCITE-1592
> URL: https://issues.apache.org/jira/browse/CALCITE-1592
> Project: Calcite
> Issue Type: Bug
>Reporter: hongbin ma
> Fix For: 1.12.0
>
>
> when we're upgrading from calcite 1.10 to 1.11. we meet found that the
> following query:
> {code:java}
> /**
>* Reads from a table.
>*/
> @Test public void testSelectx() throws SQLException {
> checkSql("model", "select * from EMPS where not (name not in ('Fred') )");
> }
> {code}
> will throw:
> {code}
> java.sql.SQLException: Error while executing SQL "select * from EMPS where
> not (name not in ('Fred') )": class org.apache.calcite.sql.SqlBasicCall:
> `EMPS`.`NAME` IN ('Fred')
> 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.CsvTest.checkSql(CsvTest.java:322)
> at org.apache.calcite.test.CsvTest.checkSql(CsvTest.java:275)
> at org.apache.calcite.test.CsvTest.testSelectx(CsvTest.java:175)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> 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:51)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:237)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
> Caused by: java.lang.UnsupportedOperationException: class
> org.apache.calcite.sql.SqlBasicCall: `EMPS`.`NAME` IN ('Fred')
> at org.apache.calcite.util.Util.needToImplement(Util.java:927)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.getValidatedNodeType(SqlValidatorImpl.java:1457)
> at
> org.apache.calcite.sql2rel.StandardConvertletTable.castToValidatedType(StandardConvertletTable.java:1304)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:4134)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertWhere(SqlToRelConverter.java:960)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:645)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:623)
> at
>
[jira] [Resolved] (CALCITE-1590) Support Guava version 21.0
[
https://issues.apache.org/jira/browse/CALCITE-1590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde resolved CALCITE-1590.
--
Resolution: Fixed
Fix Version/s: 1.12.0
Fixed in http://git-wip-us.apache.org/repos/asf/calcite/commit/f10810a2.
> Support Guava version 21.0
> --
>
> Key: CALCITE-1590
> URL: https://issues.apache.org/jira/browse/CALCITE-1590
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
> Fix For: 1.12.0
>
>
> Guava version 21.0 is an important version because it is the first with JDK 8
> support (hence lambdas). Make sure that Calcite runs on it (on JDK 8 and
> later). Continue to support other versions of Guava as early as 14.0.1.
> Compilation using {{mvn clean -Dguava.version=21.0 clean test}} on JDK8
> currently yields many errors like the following:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.5.1:compile
> (default-compile) on project calcite-core: Compilation failure: Compilation
> failure:
> [ERROR]
> /Users/jhyde/open1/calcite.2/core/src/main/java/org/apache/calcite/rel/core/Values.java:[68,31]
> is not abstract and does
> not override abstract method test(org.apache.calcite.rel.core.Values) in
> java.util.function.Predicate
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1561) Intermittent test failures
[
https://issues.apache.org/jira/browse/CALCITE-1561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15830379#comment-15830379
]
Julian Hyde commented on CALCITE-1561:
--
3. CalciteRemoteDriverTest.testRemoteExecuteQuery2 (under JDK9)
{noformat}
Running org.apache.calcite.jdbc.CalciteRemoteDriverTest
Tests run: 27, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.558 sec <<<
FAILURE! - in org.apache.calcite.jdbc.CalciteRemoteDriverTest
testRemoteExecuteQuery2(org.apache.calcite.jdbc.CalciteRemoteDriverTest) Time
elapsed: 0.063 sec <<< ERROR!
org.apache.calcite.avatica.AvaticaSqlException: Error -1 (0) : Error while
executing SQL "values (1, 'a'), (cast(null as integer), 'b')": Remote driver
error: RuntimeException: org.apache.calcite.avatica.NoSuchStatementException ->
NoSuchStatementException: (null exception message)
at
org.apache.calcite.jdbc.CalciteRemoteDriverTest.testRemoteExecuteQuery2(CalciteRemoteDriverTest.java:296)
{noformat}
> Intermittent test failures
> --
>
> Key: CALCITE-1561
> URL: https://issues.apache.org/jira/browse/CALCITE-1561
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>
> A few tests are currently failing intermittently.
> 1. UdfTest
> {noformat}
> UdfTest.testUserDefinedFunction:162
> Expected: is <9>
> but: was <10>
> {noformat}
> 2. StreamTest.testInfiniteStreamsDoNotBufferInMemory
> {noformat}
> FAILURE! - in org.apache.calcite.test.StreamTest
> testInfiniteStreamsDoNotBufferInMemory(org.apache.calcite.test.StreamTest)
> Time elapsed: 0.218 sec <<< ERROR!
> java.lang.RuntimeException: exception while executing [select stream * from
> orders]
> at
> org.apache.calcite.test.StreamTest.testInfiniteStreamsDoNotBufferInMemory(StreamTest.java:237)
> Caused by: java.util.NoSuchElementException
> at
> org.apache.calcite.test.StreamTest.testInfiniteStreamsDoNotBufferInMemory(StreamTest.java:237)
> {noformat}
> I don't consider any of them serious -- they are test issues, not product
> correctness issues -- but they are inconvenient because false negatives waste
> developer time.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1577) Druid adapter: Incorrect result - limit on timestamp disappears
[
https://issues.apache.org/jira/browse/CALCITE-1577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15830352#comment-15830352
]
Jesus Camacho Rodriguez commented on CALCITE-1577:
--
[~julianhyde], I have created a fix for this in
https://github.com/julianhyde/calcite/pull/9/commits/66339365bd40119d7bba5fa3ba42e5bbac6835d0
. I created a PR against CALCITE-1578 too. Could you review the new code and
merge it into your branch?
The PR contains tests. However, one of the tests does not currently pass, as
the Sort operation is not pushed into Druid. I double-checked and logic is
correct, hence I think it has to do with the optimizer and the cost of the
expression.
For those new tests in the PR, which are transformed into timeseries queries, I
do not run the query against Druid: in my environment, Druid crashes (probably
not enough memory to execute timeseries + sort).
> Druid adapter: Incorrect result - limit on timestamp disappears
> ---
>
> Key: CALCITE-1577
> URL: https://issues.apache.org/jira/browse/CALCITE-1577
> Project: Calcite
> Issue Type: Bug
> Components: druid
>Affects Versions: 1.11.0
>Reporter: Jesus Camacho Rodriguez
>Assignee: Jesus Camacho Rodriguez
>Priority: Critical
>
> This can be observed with the following query:
> {code:sql}
> SELECT DISTINCT `__time`
> FROM store_sales_sold_time_subset
> ORDER BY `__time` ASC
> LIMIT 10;
> {code}
> Query is translated to Druid _timeseries_, but _limit_ operator disappears.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1569) Date condition can generates Integer == Integer, which is always false
[
https://issues.apache.org/jira/browse/CALCITE-1569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15829980#comment-15829980
]
liyang commented on CALCITE-1569:
-
Thanks guys for making the progress. Let me know if the original full source is
still needed. I can reproduce the error on my side again.
> Date condition can generates Integer == Integer, which is always false
> --
>
> Key: CALCITE-1569
> URL: https://issues.apache.org/jira/browse/CALCITE-1569
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.10.0
>Reporter: liyang
>Assignee: Julian Hyde
>
> Run the below query on calcite 1.10.
> {code}
> select
> l.cal_dt
> , sum(left_join_gvm) as left_join_sum
> , sum(inner_join_gvm) as inner_join_sum
> from
> (
> select test_kylin_fact.cal_dt, sum(price) as left_join_gvm
> from test_kylin_fact
> group by test_kylin_fact.cal_dt
> ) l
> ,
> (
> select test_kylin_fact.cal_dt, sum(price) as inner_join_gvm
> from test_kylin_fact
> group by test_kylin_fact.cal_dt
> ) i
> where
> l.cal_dt = i.cal_dt-- this condition
> group by
> l.cal_dt
> {code}
> The where condition generates Baz code like below.
> {code}
> /* 284 */ final org.apache.calcite.linq4j.AbstractEnumerable child1 = new
> org.apache.calcite.linq4j.AbstractEnumerable(){
> /* 285 */ public org.apache.calcite.linq4j.Enumerator enumerator() {
> /* 286 */ return new org.apache.calcite.linq4j.Enumerator(){
> /* 287 */ public final org.apache.calcite.linq4j.Enumerator
> inputEnumerator = _inputEnumerable1.enumerator();
> /* 288 */ public void reset() {
> /* 289 */ inputEnumerator.reset();
> /* 290 */ }
> /* 291 */
> /* 292 */ public boolean moveNext() {
> /* 293 */ while (inputEnumerator.moveNext()) {
> /* 294 */ final Object[] current = (Object[])
> inputEnumerator.current();
> /* 295 */ final Integer inp0_ = (Integer) current[0];
> /* 296 */ final Integer inp2_ = (Integer) current[2];
> /* 297 */ if (inp0_ != null && inp2_ != null && inp0_ == inp2_)
> {
> /* 298 */ return true;
> /* 299 */ }
> /* 300 */ }
> /* 301 */ return false;
> /* 302 */ }
> /* 303 */
> /* 304 */ public void close() {
> /* 305 */ inputEnumerator.close();
> /* 306 */ }
> /* 307 */
> /* 308 */ public Object current() {
> /* 309 */ final Object[] current = (Object[])
> inputEnumerator.current();
> /* 310 */ return new Object[] {
> /* 311 */ current[0],
> /* 312 */ current[1],
> /* 313 */ current[3]};
> /* 314 */ }
> /* 315 */
> /* 316 */ };
> /* 317 */ }
> /* 318 */
> /* 319 */ };
> {code}
> The problem is {code} if (inp0_ != null && inp2_ != null && inp0_ == inp2_)
> {code} is always false, by using == to compare two Integers.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
