[jira] [Resolved] (CALCITE-2137) Materialized view rewriting not being triggered for some join queries
[
https://issues.apache.org/jira/browse/CALCITE-2137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jesus Camacho Rodriguez resolved CALCITE-2137.
--
Resolution: Fixed
Fixed in http://git-wip-us.apache.org/repos/asf/calcite/commit/73e57ad48 .
> Materialized view rewriting not being triggered for some join queries
> -
>
> Key: CALCITE-2137
> URL: https://issues.apache.org/jira/browse/CALCITE-2137
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Jesus Camacho Rodriguez
>Assignee: Jesus Camacho Rodriguez
>Priority: Major
> Labels: materializedviews
> Fix For: 1.16.0
>
>
> The issue has to do with the column equivalences mapping for joins with
> equality predicates for columns that are output by the query or subquery
> (basically, there is a bug and we do not apply mapping). This results in
> missing rewriting opportunities as the top expression cannot be mapped from
> the query to the view. It can be reproduced with the following MV and query
> in {{MaterializationTest.java}}:
> MV:
> {code}
> select *
> from "emps"
> join "dependents" using ("empid");
> {code}
> Query:
> {code}
> select "emps"."empid", "dependents"."empid", "emps"."deptno"
> from "emps"
> join "dependents" using ("empid")
> join "depts" "a" on ("emps"."deptno"="a"."deptno")
> where "emps"."name" = 'Bill';
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CALCITE-2137) Materialized view rewriting not being triggered for some join queries
Jesus Camacho Rodriguez created CALCITE-2137:
Summary: Materialized view rewriting not being triggered for some
join queries
Key: CALCITE-2137
URL: https://issues.apache.org/jira/browse/CALCITE-2137
Project: Calcite
Issue Type: Bug
Components: core
Reporter: Jesus Camacho Rodriguez
Assignee: Jesus Camacho Rodriguez
Fix For: 1.16.0
The issue has to do with the column equivalences mapping for joins with
equality predicates for columns that are output by the query or subquery
(basically, there is a bug and we do not apply mapping). This results in
missing rewriting opportunities as the top expression cannot be mapped from the
query to the view. It can be reproduced with the following MV and query in
{{MaterializationTest.java}}:
MV:
{code}
select *
from "emps"
join "dependents" using ("empid");
{code}
Query:
{code}
select "emps"."empid", "dependents"."empid", "emps"."deptno"
from "emps"
join "dependents" using ("empid")
join "depts" "a" on ("emps"."deptno"="a"."deptno")
where "emps"."name" = 'Bill';
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2133) Allow SqlGroupedWindowFunction to specify returnTypeInference in its constructor
[ https://issues.apache.org/jira/browse/CALCITE-2133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16328182#comment-16328182 ] Shuyi Chen commented on CALCITE-2133: - Thanks a lot for the review, [~julianhyde]. Could you please help take another look at the [PR|https://github.com/apache/calcite/pull/606]? > Allow SqlGroupedWindowFunction to specify returnTypeInference in its > constructor > > > Key: CALCITE-2133 > URL: https://issues.apache.org/jira/browse/CALCITE-2133 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.16.0 >Reporter: Shuyi Chen >Assignee: Julian Hyde >Priority: Major > Fix For: 1.16.0 > > > This is follow-up of CALCITE-1867; we need to add a new constructor to allow > Flink to pass in the returnTypeInference parameter. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2107) Timezone not passed as part of granularity when passing TimeExtractionFunction to Druid
[
https://issues.apache.org/jira/browse/CALCITE-2107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16328008#comment-16328008
]
Julian Hyde commented on CALCITE-2107:
--
Re-reading code, I now see that Granularity is part of the Druid query spec,
not part of the SQL or RelNode query spec. So, I now agree that it makes sense
that it contains time zone. Sorry about that.
Left to do:
* Improve javadoc comments. (I get now that AllGranularity is a singleton
pattern implemented as an enum. And I get now that Granularity is intended to
generate a JSON fragment as part of a Druid query. And in Druid, granularity is
just a particular time period over which Druid is able to roll up and round
timestamp values.)
* I suggest that you make {{AllGranularity}} and {{PeriodGranularity}} private,
i.e. put them in a class called {{Granularities}} with some factory methods.
All other code should work in terms of the {{Granularity}} interface.
* The fields of {{PeriodGranularity}} seem to be mandatory. If so, add
preconditions in the constructor.
* You must not call {{Locale.getDefault()}}; I thought we disallowed such calls
in CALCITE-1667, but maybe the forbidden-apis checker is not working.
> Timezone not passed as part of granularity when passing
> TimeExtractionFunction to Druid
> ---
>
> Key: CALCITE-2107
> URL: https://issues.apache.org/jira/browse/CALCITE-2107
> Project: Calcite
> Issue Type: Bug
> Components: druid
>Reporter: Nishant Bangarwa
>Assignee: Nishant Bangarwa
>Priority: Major
>
> When sending granularity to TimeFormatExtractionFunction we need to add
> timezone to the granularity to align it with the timezone specified in
> calcite connection. If no timezone is specified in granularity, It is
> considered as UTC timezone by druid.
> Note the return value in is as per granularity UTC and not IST as expected -
> {code}
> @Test
> public void testTmeWithFilterOnFloorOnTimeWithTimezoneConversion() {
> final String sql = "Select cast(floor(\"timestamp\" to MONTH) as
> timestamp) as t from "
> + "\"foodmart\" where floor(\"timestamp\" to MONTH) >= '1997-04-30
> 18:30:00 UTC' order by t"
> + " limit 1";
> final String druidQueryPart1 =
> "filter\":{\"type\":\"bound\",\"dimension\":\"__time\","
> + "\"lower\":\"1997-05-01T00:00:00.000Z\",\"lowerStrict\":false,"
> +
> "\"ordering\":\"lexicographic\",\"extractionFn\":{\"type\":\"timeFormat\","
> + "\"format\":\"-MM-dd";
> final String druidQueryPart2 =
> "\"granularity\":\"month\",\"timeZone\":\"IST\","
> +
> "\"locale\":\"en-US\"}},\"dimensions\":[],\"metrics\":[],\"granularity\":\"all\"";
> CalciteAssert.that()
> .enable(enabled())
> .with(ImmutableMap.of("model", FOODMART.getPath()))
> .with(CalciteConnectionProperty.TIME_ZONE.camelName(), "IST")
> .query(sql)
> .runs()
> .queryContains(druidChecker(druidQueryPart1, druidQueryPart2))
> .returnsOrdered("T=1997-05-01 05:30:00");
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-1188) NullPointerException in EXTRACT with WHERE ... IN clause if field has null value
[ https://issues.apache.org/jira/browse/CALCITE-1188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16327949#comment-16327949 ] Alessandro Solimando commented on CALCITE-1188: --- In the meantime I have issued a second PR (#608 after #607 that now looks empty) to fix an indentation issue. PR [https://github.com/apache/calcite/pull/608] should be fine, could you please double check? > NullPointerException in EXTRACT with WHERE ... IN clause if field has null > value > > > Key: CALCITE-1188 > URL: https://issues.apache.org/jira/browse/CALCITE-1188 > Project: Calcite > Issue Type: Bug >Affects Versions: 1.7.0 >Reporter: Wei Hu >Assignee: Julian Hyde >Priority: Major > Labels: newbie > > if there was a timestamp or date field F1, the queries below will throw > nullpointer exception if F1 has null value > select extract(year from F1) from T where extract(year from F1) in (2004, > 2005) > select extract(year from F1) , count(0) from T where extract(year from F1) in > (2004, 2005) group by extract(year from F1) > the number of items in WHERE-IN clause must be equal or more than two -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-1188) NullPointerException in EXTRACT with WHERE ... IN clause if field has null value
[ https://issues.apache.org/jira/browse/CALCITE-1188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16327937#comment-16327937 ] Julian Hyde commented on CALCITE-1188: -- That pull request is currently empty - it has zero commits. Can you please make a commit of your test, and push it to your master branch at github. (Sorry for all the red tape. The ASF needs to see a commit in a pull request as an indication that you intend to contribute code.) > NullPointerException in EXTRACT with WHERE ... IN clause if field has null > value > > > Key: CALCITE-1188 > URL: https://issues.apache.org/jira/browse/CALCITE-1188 > Project: Calcite > Issue Type: Bug >Affects Versions: 1.7.0 >Reporter: Wei Hu >Assignee: Julian Hyde >Priority: Major > Labels: newbie > > if there was a timestamp or date field F1, the queries below will throw > nullpointer exception if F1 has null value > select extract(year from F1) from T where extract(year from F1) in (2004, > 2005) > select extract(year from F1) , count(0) from T where extract(year from F1) in > (2004, 2005) group by extract(year from F1) > the number of items in WHERE-IN clause must be equal or more than two -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-1188) NullPointerException in EXTRACT with WHERE ... IN clause if field has null value
[ https://issues.apache.org/jira/browse/CALCITE-1188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16327842#comment-16327842 ] Alessandro Solimando edited comment on CALCITE-1188 at 1/16/18 10:18 PM: - Hi Julian, this is the PR with the test covering the ticket: [https://github.com/apache/calcite/pull/608|https://github.com/apache/calcite/pull/608] was (Author: asolimando): Hi Julian, this is the PR with the test covering the ticket: [https://github.com/apache/calcite/pull/60|https://github.com/apache/calcite/pull/607]8 > NullPointerException in EXTRACT with WHERE ... IN clause if field has null > value > > > Key: CALCITE-1188 > URL: https://issues.apache.org/jira/browse/CALCITE-1188 > Project: Calcite > Issue Type: Bug >Affects Versions: 1.7.0 >Reporter: Wei Hu >Assignee: Julian Hyde >Priority: Major > Labels: newbie > > if there was a timestamp or date field F1, the queries below will throw > nullpointer exception if F1 has null value > select extract(year from F1) from T where extract(year from F1) in (2004, > 2005) > select extract(year from F1) , count(0) from T where extract(year from F1) in > (2004, 2005) group by extract(year from F1) > the number of items in WHERE-IN clause must be equal or more than two -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-1188) NullPointerException in EXTRACT with WHERE ... IN clause if field has null value
[ https://issues.apache.org/jira/browse/CALCITE-1188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16327842#comment-16327842 ] Alessandro Solimando edited comment on CALCITE-1188 at 1/16/18 10:18 PM: - Hi Julian, this is the PR with the test covering the ticket: [https://github.com/apache/calcite/pull/60|https://github.com/apache/calcite/pull/607]8 was (Author: asolimando): Hi Julian, this is the PR with the test covering the ticket: [https://github.com/apache/calcite/pull/607] > NullPointerException in EXTRACT with WHERE ... IN clause if field has null > value > > > Key: CALCITE-1188 > URL: https://issues.apache.org/jira/browse/CALCITE-1188 > Project: Calcite > Issue Type: Bug >Affects Versions: 1.7.0 >Reporter: Wei Hu >Assignee: Julian Hyde >Priority: Major > Labels: newbie > > if there was a timestamp or date field F1, the queries below will throw > nullpointer exception if F1 has null value > select extract(year from F1) from T where extract(year from F1) in (2004, > 2005) > select extract(year from F1) , count(0) from T where extract(year from F1) in > (2004, 2005) group by extract(year from F1) > the number of items in WHERE-IN clause must be equal or more than two -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-1188) NullPointerException in EXTRACT with WHERE ... IN clause if field has null value
[ https://issues.apache.org/jira/browse/CALCITE-1188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16327842#comment-16327842 ] Alessandro Solimando edited comment on CALCITE-1188 at 1/16/18 9:26 PM: Hi Julian, this is the PR with the test covering the ticket: [https://github.com/apache/calcite/pull/607] was (Author: asolimando): Hi Julian, this is the PR with the test covering the ticket: [#https://github.com/apache/calcite/pull/607] > NullPointerException in EXTRACT with WHERE ... IN clause if field has null > value > > > Key: CALCITE-1188 > URL: https://issues.apache.org/jira/browse/CALCITE-1188 > Project: Calcite > Issue Type: Bug >Affects Versions: 1.7.0 >Reporter: Wei Hu >Assignee: Julian Hyde >Priority: Major > Labels: newbie > > if there was a timestamp or date field F1, the queries below will throw > nullpointer exception if F1 has null value > select extract(year from F1) from T where extract(year from F1) in (2004, > 2005) > select extract(year from F1) , count(0) from T where extract(year from F1) in > (2004, 2005) group by extract(year from F1) > the number of items in WHERE-IN clause must be equal or more than two -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-1188) NullPointerException in EXTRACT with WHERE ... IN clause if field has null value
[ https://issues.apache.org/jira/browse/CALCITE-1188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16327842#comment-16327842 ] Alessandro Solimando commented on CALCITE-1188: --- Hi Julian, this is the PR with the test covering the ticket: [#https://github.com/apache/calcite/pull/607] > NullPointerException in EXTRACT with WHERE ... IN clause if field has null > value > > > Key: CALCITE-1188 > URL: https://issues.apache.org/jira/browse/CALCITE-1188 > Project: Calcite > Issue Type: Bug >Affects Versions: 1.7.0 >Reporter: Wei Hu >Assignee: Julian Hyde >Priority: Major > Labels: newbie > > if there was a timestamp or date field F1, the queries below will throw > nullpointer exception if F1 has null value > select extract(year from F1) from T where extract(year from F1) in (2004, > 2005) > select extract(year from F1) , count(0) from T where extract(year from F1) in > (2004, 2005) group by extract(year from F1) > the number of items in WHERE-IN clause must be equal or more than two -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2107) Timezone not passed as part of granularity when passing TimeExtractionFunction to Druid
[
https://issues.apache.org/jira/browse/CALCITE-2107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16327812#comment-16327812
]
Julian Hyde commented on CALCITE-2107:
--
I'm not sure about that. The time zone does not need to flow with the data; it
is only needed when certain operations are performed, say truncating to day.
Other operations e.g. IS NULL or {{>}} do not need to know time zone.
Which is the same as saying that time zone is part of the query, not part of
the data.
(There may be other cases I'm not aware of where time zone is genuinely part of
the data. We can address those separately. And maybe the TIMESTAMP WITH TIME
ZONE type is required for those.)
> Timezone not passed as part of granularity when passing
> TimeExtractionFunction to Druid
> ---
>
> Key: CALCITE-2107
> URL: https://issues.apache.org/jira/browse/CALCITE-2107
> Project: Calcite
> Issue Type: Bug
> Components: druid
>Reporter: Nishant Bangarwa
>Assignee: Nishant Bangarwa
>Priority: Major
>
> When sending granularity to TimeFormatExtractionFunction we need to add
> timezone to the granularity to align it with the timezone specified in
> calcite connection. If no timezone is specified in granularity, It is
> considered as UTC timezone by druid.
> Note the return value in is as per granularity UTC and not IST as expected -
> {code}
> @Test
> public void testTmeWithFilterOnFloorOnTimeWithTimezoneConversion() {
> final String sql = "Select cast(floor(\"timestamp\" to MONTH) as
> timestamp) as t from "
> + "\"foodmart\" where floor(\"timestamp\" to MONTH) >= '1997-04-30
> 18:30:00 UTC' order by t"
> + " limit 1";
> final String druidQueryPart1 =
> "filter\":{\"type\":\"bound\",\"dimension\":\"__time\","
> + "\"lower\":\"1997-05-01T00:00:00.000Z\",\"lowerStrict\":false,"
> +
> "\"ordering\":\"lexicographic\",\"extractionFn\":{\"type\":\"timeFormat\","
> + "\"format\":\"-MM-dd";
> final String druidQueryPart2 =
> "\"granularity\":\"month\",\"timeZone\":\"IST\","
> +
> "\"locale\":\"en-US\"}},\"dimensions\":[],\"metrics\":[],\"granularity\":\"all\"";
> CalciteAssert.that()
> .enable(enabled())
> .with(ImmutableMap.of("model", FOODMART.getPath()))
> .with(CalciteConnectionProperty.TIME_ZONE.camelName(), "IST")
> .query(sql)
> .runs()
> .queryContains(druidChecker(druidQueryPart1, druidQueryPart2))
> .returnsOrdered("T=1997-05-01 05:30:00");
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2107) Timezone not passed as part of granularity when passing TimeExtractionFunction to Druid
[
https://issues.apache.org/jira/browse/CALCITE-2107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16327804#comment-16327804
]
Jesus Camacho Rodriguez commented on CALCITE-2107:
--
That can be quite difficult since every function that inputs/outputs
{{timestamp with local time zone}} values should be parameterized then.
> Timezone not passed as part of granularity when passing
> TimeExtractionFunction to Druid
> ---
>
> Key: CALCITE-2107
> URL: https://issues.apache.org/jira/browse/CALCITE-2107
> Project: Calcite
> Issue Type: Bug
> Components: druid
>Reporter: Nishant Bangarwa
>Assignee: Nishant Bangarwa
>Priority: Major
>
> When sending granularity to TimeFormatExtractionFunction we need to add
> timezone to the granularity to align it with the timezone specified in
> calcite connection. If no timezone is specified in granularity, It is
> considered as UTC timezone by druid.
> Note the return value in is as per granularity UTC and not IST as expected -
> {code}
> @Test
> public void testTmeWithFilterOnFloorOnTimeWithTimezoneConversion() {
> final String sql = "Select cast(floor(\"timestamp\" to MONTH) as
> timestamp) as t from "
> + "\"foodmart\" where floor(\"timestamp\" to MONTH) >= '1997-04-30
> 18:30:00 UTC' order by t"
> + " limit 1";
> final String druidQueryPart1 =
> "filter\":{\"type\":\"bound\",\"dimension\":\"__time\","
> + "\"lower\":\"1997-05-01T00:00:00.000Z\",\"lowerStrict\":false,"
> +
> "\"ordering\":\"lexicographic\",\"extractionFn\":{\"type\":\"timeFormat\","
> + "\"format\":\"-MM-dd";
> final String druidQueryPart2 =
> "\"granularity\":\"month\",\"timeZone\":\"IST\","
> +
> "\"locale\":\"en-US\"}},\"dimensions\":[],\"metrics\":[],\"granularity\":\"all\"";
> CalciteAssert.that()
> .enable(enabled())
> .with(ImmutableMap.of("model", FOODMART.getPath()))
> .with(CalciteConnectionProperty.TIME_ZONE.camelName(), "IST")
> .query(sql)
> .runs()
> .queryContains(druidChecker(druidQueryPart1, druidQueryPart2))
> .returnsOrdered("T=1997-05-01 05:30:00");
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2128) Add jethro sql dialect and jdbc support
[ https://issues.apache.org/jira/browse/CALCITE-2128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16327801#comment-16327801 ] Julian Hyde commented on CALCITE-2128: -- I see you've added a couple of commits. Shall I review again? Post a comment in this case when you're ready to review. > Add jethro sql dialect and jdbc support > --- > > Key: CALCITE-2128 > URL: https://issues.apache.org/jira/browse/CALCITE-2128 > Project: Calcite > Issue Type: Improvement > Components: jdbc-adapter >Reporter: Jonathan Doron >Assignee: Jonathan Doron >Priority: Major > Fix For: 1.16.0 > > > Calcite Jdbc operators code needs to be public so it could be used in hive > code to support usage of external jdbc tables in hive -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2107) Timezone not passed as part of granularity when passing TimeExtractionFunction to Druid
[
https://issues.apache.org/jira/browse/CALCITE-2107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16327798#comment-16327798
]
Julian Hyde commented on CALCITE-2107:
--
Another option (not necessarily my favorite) is to add a time zone parameter to
applicable functions.
> Timezone not passed as part of granularity when passing
> TimeExtractionFunction to Druid
> ---
>
> Key: CALCITE-2107
> URL: https://issues.apache.org/jira/browse/CALCITE-2107
> Project: Calcite
> Issue Type: Bug
> Components: druid
>Reporter: Nishant Bangarwa
>Assignee: Nishant Bangarwa
>Priority: Major
>
> When sending granularity to TimeFormatExtractionFunction we need to add
> timezone to the granularity to align it with the timezone specified in
> calcite connection. If no timezone is specified in granularity, It is
> considered as UTC timezone by druid.
> Note the return value in is as per granularity UTC and not IST as expected -
> {code}
> @Test
> public void testTmeWithFilterOnFloorOnTimeWithTimezoneConversion() {
> final String sql = "Select cast(floor(\"timestamp\" to MONTH) as
> timestamp) as t from "
> + "\"foodmart\" where floor(\"timestamp\" to MONTH) >= '1997-04-30
> 18:30:00 UTC' order by t"
> + " limit 1";
> final String druidQueryPart1 =
> "filter\":{\"type\":\"bound\",\"dimension\":\"__time\","
> + "\"lower\":\"1997-05-01T00:00:00.000Z\",\"lowerStrict\":false,"
> +
> "\"ordering\":\"lexicographic\",\"extractionFn\":{\"type\":\"timeFormat\","
> + "\"format\":\"-MM-dd";
> final String druidQueryPart2 =
> "\"granularity\":\"month\",\"timeZone\":\"IST\","
> +
> "\"locale\":\"en-US\"}},\"dimensions\":[],\"metrics\":[],\"granularity\":\"all\"";
> CalciteAssert.that()
> .enable(enabled())
> .with(ImmutableMap.of("model", FOODMART.getPath()))
> .with(CalciteConnectionProperty.TIME_ZONE.camelName(), "IST")
> .query(sql)
> .runs()
> .queryContains(druidChecker(druidQueryPart1, druidQueryPart2))
> .returnsOrdered("T=1997-05-01 05:30:00");
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2107) Timezone not passed as part of granularity when passing TimeExtractionFunction to Druid
[
https://issues.apache.org/jira/browse/CALCITE-2107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16327781#comment-16327781
]
Jesus Camacho Rodriguez edited comment on CALCITE-2107 at 1/16/18 8:54 PM:
---
OK, I got your point. The only way that I can think of to not rely on session
information throughout the optimization is parameterizing the {{timestamp with
local time zone}} type? That would imply changing the internal representation
of {{timestamp with local time zone}} values from {{TimestampString}} to
{{TimestampWithTimeZoneString}}?
was (Author: jcamachorodriguez):
OK, I got your point. The only way that I can think of to not rely on session
information throughout the optimization is parameterizing the {{timestamp with
local time zone}} type?
> Timezone not passed as part of granularity when passing
> TimeExtractionFunction to Druid
> ---
>
> Key: CALCITE-2107
> URL: https://issues.apache.org/jira/browse/CALCITE-2107
> Project: Calcite
> Issue Type: Bug
> Components: druid
>Reporter: Nishant Bangarwa
>Assignee: Nishant Bangarwa
>Priority: Major
>
> When sending granularity to TimeFormatExtractionFunction we need to add
> timezone to the granularity to align it with the timezone specified in
> calcite connection. If no timezone is specified in granularity, It is
> considered as UTC timezone by druid.
> Note the return value in is as per granularity UTC and not IST as expected -
> {code}
> @Test
> public void testTmeWithFilterOnFloorOnTimeWithTimezoneConversion() {
> final String sql = "Select cast(floor(\"timestamp\" to MONTH) as
> timestamp) as t from "
> + "\"foodmart\" where floor(\"timestamp\" to MONTH) >= '1997-04-30
> 18:30:00 UTC' order by t"
> + " limit 1";
> final String druidQueryPart1 =
> "filter\":{\"type\":\"bound\",\"dimension\":\"__time\","
> + "\"lower\":\"1997-05-01T00:00:00.000Z\",\"lowerStrict\":false,"
> +
> "\"ordering\":\"lexicographic\",\"extractionFn\":{\"type\":\"timeFormat\","
> + "\"format\":\"-MM-dd";
> final String druidQueryPart2 =
> "\"granularity\":\"month\",\"timeZone\":\"IST\","
> +
> "\"locale\":\"en-US\"}},\"dimensions\":[],\"metrics\":[],\"granularity\":\"all\"";
> CalciteAssert.that()
> .enable(enabled())
> .with(ImmutableMap.of("model", FOODMART.getPath()))
> .with(CalciteConnectionProperty.TIME_ZONE.camelName(), "IST")
> .query(sql)
> .runs()
> .queryContains(druidChecker(druidQueryPart1, druidQueryPart2))
> .returnsOrdered("T=1997-05-01 05:30:00");
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2107) Timezone not passed as part of granularity when passing TimeExtractionFunction to Druid
[
https://issues.apache.org/jira/browse/CALCITE-2107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16327781#comment-16327781
]
Jesus Camacho Rodriguez edited comment on CALCITE-2107 at 1/16/18 8:52 PM:
---
OK, I got your point. The only way that I can think of to not rely on session
information throughout the optimization is parameterizing the {{timestamp with
local time zone}} type?
was (Author: jcamachorodriguez):
OK, I got your point. I have just revisited CALCITE-1947 and it seems to me
that we chose to represent {{timestamp with local time zone}} as
{{TimestampWithTimeZone}} literal for the same reason, so the information is
explicit within the value. For the granularity, this seems a bit more
complicated to do. The only way I can think of is parameterizing the
{{timestamp with local time zone}} type?
> Timezone not passed as part of granularity when passing
> TimeExtractionFunction to Druid
> ---
>
> Key: CALCITE-2107
> URL: https://issues.apache.org/jira/browse/CALCITE-2107
> Project: Calcite
> Issue Type: Bug
> Components: druid
>Reporter: Nishant Bangarwa
>Assignee: Nishant Bangarwa
>Priority: Major
>
> When sending granularity to TimeFormatExtractionFunction we need to add
> timezone to the granularity to align it with the timezone specified in
> calcite connection. If no timezone is specified in granularity, It is
> considered as UTC timezone by druid.
> Note the return value in is as per granularity UTC and not IST as expected -
> {code}
> @Test
> public void testTmeWithFilterOnFloorOnTimeWithTimezoneConversion() {
> final String sql = "Select cast(floor(\"timestamp\" to MONTH) as
> timestamp) as t from "
> + "\"foodmart\" where floor(\"timestamp\" to MONTH) >= '1997-04-30
> 18:30:00 UTC' order by t"
> + " limit 1";
> final String druidQueryPart1 =
> "filter\":{\"type\":\"bound\",\"dimension\":\"__time\","
> + "\"lower\":\"1997-05-01T00:00:00.000Z\",\"lowerStrict\":false,"
> +
> "\"ordering\":\"lexicographic\",\"extractionFn\":{\"type\":\"timeFormat\","
> + "\"format\":\"-MM-dd";
> final String druidQueryPart2 =
> "\"granularity\":\"month\",\"timeZone\":\"IST\","
> +
> "\"locale\":\"en-US\"}},\"dimensions\":[],\"metrics\":[],\"granularity\":\"all\"";
> CalciteAssert.that()
> .enable(enabled())
> .with(ImmutableMap.of("model", FOODMART.getPath()))
> .with(CalciteConnectionProperty.TIME_ZONE.camelName(), "IST")
> .query(sql)
> .runs()
> .queryContains(druidChecker(druidQueryPart1, druidQueryPart2))
> .returnsOrdered("T=1997-05-01 05:30:00");
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2107) Timezone not passed as part of granularity when passing TimeExtractionFunction to Druid
[
https://issues.apache.org/jira/browse/CALCITE-2107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16327781#comment-16327781
]
Jesus Camacho Rodriguez commented on CALCITE-2107:
--
OK, I got your point. I have just revisited CALCITE-1947 and it seems to me
that we chose to represent {{timestamp with local time zone}} as
{{TimestampWithTimeZone}} literal for the same reason, so the information is
explicit within the value. For the granularity, this seems a bit more
complicated to do. The only way I can think of is parameterizing the
{{timestamp with local time zone}} type?
> Timezone not passed as part of granularity when passing
> TimeExtractionFunction to Druid
> ---
>
> Key: CALCITE-2107
> URL: https://issues.apache.org/jira/browse/CALCITE-2107
> Project: Calcite
> Issue Type: Bug
> Components: druid
>Reporter: Nishant Bangarwa
>Assignee: Nishant Bangarwa
>Priority: Major
>
> When sending granularity to TimeFormatExtractionFunction we need to add
> timezone to the granularity to align it with the timezone specified in
> calcite connection. If no timezone is specified in granularity, It is
> considered as UTC timezone by druid.
> Note the return value in is as per granularity UTC and not IST as expected -
> {code}
> @Test
> public void testTmeWithFilterOnFloorOnTimeWithTimezoneConversion() {
> final String sql = "Select cast(floor(\"timestamp\" to MONTH) as
> timestamp) as t from "
> + "\"foodmart\" where floor(\"timestamp\" to MONTH) >= '1997-04-30
> 18:30:00 UTC' order by t"
> + " limit 1";
> final String druidQueryPart1 =
> "filter\":{\"type\":\"bound\",\"dimension\":\"__time\","
> + "\"lower\":\"1997-05-01T00:00:00.000Z\",\"lowerStrict\":false,"
> +
> "\"ordering\":\"lexicographic\",\"extractionFn\":{\"type\":\"timeFormat\","
> + "\"format\":\"-MM-dd";
> final String druidQueryPart2 =
> "\"granularity\":\"month\",\"timeZone\":\"IST\","
> +
> "\"locale\":\"en-US\"}},\"dimensions\":[],\"metrics\":[],\"granularity\":\"all\"";
> CalciteAssert.that()
> .enable(enabled())
> .with(ImmutableMap.of("model", FOODMART.getPath()))
> .with(CalciteConnectionProperty.TIME_ZONE.camelName(), "IST")
> .query(sql)
> .runs()
> .queryContains(druidChecker(druidQueryPart1, druidQueryPart2))
> .returnsOrdered("T=1997-05-01 05:30:00");
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2107) Timezone not passed as part of granularity when passing TimeExtractionFunction to Druid
[
https://issues.apache.org/jira/browse/CALCITE-2107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16327764#comment-16327764
]
Julian Hyde commented on CALCITE-2107:
--
I contend that the time zone is part of the query definition, so needs to be
explicit. Suppose we were to add a planner rule that optimizes granularity.
That rule would need to use the implicit time zone, in order not to change
semantics. Or, suppose that we execute the query on an engine other than Druid.
Either way, it would no longer be true that the "information is being used when
the JSON object is generated from the DruidQuery node, not before".
As you already know, the implicit time zone in timestamp with local time zone
makes me uncomfortable. I am fighting here because we seem to be slipping
further down that slope.
> Timezone not passed as part of granularity when passing
> TimeExtractionFunction to Druid
> ---
>
> Key: CALCITE-2107
> URL: https://issues.apache.org/jira/browse/CALCITE-2107
> Project: Calcite
> Issue Type: Bug
> Components: druid
>Reporter: Nishant Bangarwa
>Assignee: Nishant Bangarwa
>Priority: Major
>
> When sending granularity to TimeFormatExtractionFunction we need to add
> timezone to the granularity to align it with the timezone specified in
> calcite connection. If no timezone is specified in granularity, It is
> considered as UTC timezone by druid.
> Note the return value in is as per granularity UTC and not IST as expected -
> {code}
> @Test
> public void testTmeWithFilterOnFloorOnTimeWithTimezoneConversion() {
> final String sql = "Select cast(floor(\"timestamp\" to MONTH) as
> timestamp) as t from "
> + "\"foodmart\" where floor(\"timestamp\" to MONTH) >= '1997-04-30
> 18:30:00 UTC' order by t"
> + " limit 1";
> final String druidQueryPart1 =
> "filter\":{\"type\":\"bound\",\"dimension\":\"__time\","
> + "\"lower\":\"1997-05-01T00:00:00.000Z\",\"lowerStrict\":false,"
> +
> "\"ordering\":\"lexicographic\",\"extractionFn\":{\"type\":\"timeFormat\","
> + "\"format\":\"-MM-dd";
> final String druidQueryPart2 =
> "\"granularity\":\"month\",\"timeZone\":\"IST\","
> +
> "\"locale\":\"en-US\"}},\"dimensions\":[],\"metrics\":[],\"granularity\":\"all\"";
> CalciteAssert.that()
> .enable(enabled())
> .with(ImmutableMap.of("model", FOODMART.getPath()))
> .with(CalciteConnectionProperty.TIME_ZONE.camelName(), "IST")
> .query(sql)
> .runs()
> .queryContains(druidChecker(druidQueryPart1, druidQueryPart2))
> .returnsOrdered("T=1997-05-01 05:30:00");
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-1188) NullPointerException in EXTRACT with WHERE ... IN clause if field has null value
[ https://issues.apache.org/jira/browse/CALCITE-1188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16327741#comment-16327741 ] Julian Hyde commented on CALCITE-1188: -- Your test works for me too. I suspect that the issue was fixed long ago by code generation changes. Can you create a PR for your test case? I will commit it and we can mark this bug as "fixed". (By the way, there is other work occurring on CALCITE-1054 which may improve things further.) > NullPointerException in EXTRACT with WHERE ... IN clause if field has null > value > > > Key: CALCITE-1188 > URL: https://issues.apache.org/jira/browse/CALCITE-1188 > Project: Calcite > Issue Type: Bug >Affects Versions: 1.7.0 >Reporter: Wei Hu >Assignee: Julian Hyde >Priority: Major > Labels: newbie > > if there was a timestamp or date field F1, the queries below will throw > nullpointer exception if F1 has null value > select extract(year from F1) from T where extract(year from F1) in (2004, > 2005) > select extract(year from F1) , count(0) from T where extract(year from F1) in > (2004, 2005) group by extract(year from F1) > the number of items in WHERE-IN clause must be equal or more than two -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2107) Timezone not passed as part of granularity when passing TimeExtractionFunction to Druid
[
https://issues.apache.org/jira/browse/CALCITE-2107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16327735#comment-16327735
]
Jesus Camacho Rodriguez commented on CALCITE-2107:
--
This information is being used when the JSON object is generated from the
DruidQuery node, not before. Since Druid needs that information, I am not sure
what is the alternative? Maybe Druid could include the time zone definition
globally?
We are already doing similar processing when we rely on session information
(local time zone) to fold 'timestamp with local time zone' types. If we would
move all the logic to the evaluation phase, then we might miss some
optimization opportunities.
> Timezone not passed as part of granularity when passing
> TimeExtractionFunction to Druid
> ---
>
> Key: CALCITE-2107
> URL: https://issues.apache.org/jira/browse/CALCITE-2107
> Project: Calcite
> Issue Type: Bug
> Components: druid
>Reporter: Nishant Bangarwa
>Assignee: Nishant Bangarwa
>Priority: Major
>
> When sending granularity to TimeFormatExtractionFunction we need to add
> timezone to the granularity to align it with the timezone specified in
> calcite connection. If no timezone is specified in granularity, It is
> considered as UTC timezone by druid.
> Note the return value in is as per granularity UTC and not IST as expected -
> {code}
> @Test
> public void testTmeWithFilterOnFloorOnTimeWithTimezoneConversion() {
> final String sql = "Select cast(floor(\"timestamp\" to MONTH) as
> timestamp) as t from "
> + "\"foodmart\" where floor(\"timestamp\" to MONTH) >= '1997-04-30
> 18:30:00 UTC' order by t"
> + " limit 1";
> final String druidQueryPart1 =
> "filter\":{\"type\":\"bound\",\"dimension\":\"__time\","
> + "\"lower\":\"1997-05-01T00:00:00.000Z\",\"lowerStrict\":false,"
> +
> "\"ordering\":\"lexicographic\",\"extractionFn\":{\"type\":\"timeFormat\","
> + "\"format\":\"-MM-dd";
> final String druidQueryPart2 =
> "\"granularity\":\"month\",\"timeZone\":\"IST\","
> +
> "\"locale\":\"en-US\"}},\"dimensions\":[],\"metrics\":[],\"granularity\":\"all\"";
> CalciteAssert.that()
> .enable(enabled())
> .with(ImmutableMap.of("model", FOODMART.getPath()))
> .with(CalciteConnectionProperty.TIME_ZONE.camelName(), "IST")
> .query(sql)
> .runs()
> .queryContains(druidChecker(druidQueryPart1, druidQueryPart2))
> .returnsOrdered("T=1997-05-01 05:30:00");
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2107) Timezone not passed as part of granularity when passing TimeExtractionFunction to Druid
[
https://issues.apache.org/jira/browse/CALCITE-2107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16327695#comment-16327695
]
Julian Hyde commented on CALCITE-2107:
--
I know what granularity is, but the next maintainer might not. Can you put an
adequate definition of granularity into the class javadoc comments.
You haven't explained why time zone belongs in the Granularity object. It seems
like a literal to me, so it shouldn't have "hidden" data from the current
session. Can the time zone not come from elsewhere in the validation/evaluation
context? Isn't it in the validation/evaluation context already?
I really hate the idea that a SQL query will return different results based on
hidden session information.
> Timezone not passed as part of granularity when passing
> TimeExtractionFunction to Druid
> ---
>
> Key: CALCITE-2107
> URL: https://issues.apache.org/jira/browse/CALCITE-2107
> Project: Calcite
> Issue Type: Bug
> Components: druid
>Reporter: Nishant Bangarwa
>Assignee: Nishant Bangarwa
>Priority: Major
>
> When sending granularity to TimeFormatExtractionFunction we need to add
> timezone to the granularity to align it with the timezone specified in
> calcite connection. If no timezone is specified in granularity, It is
> considered as UTC timezone by druid.
> Note the return value in is as per granularity UTC and not IST as expected -
> {code}
> @Test
> public void testTmeWithFilterOnFloorOnTimeWithTimezoneConversion() {
> final String sql = "Select cast(floor(\"timestamp\" to MONTH) as
> timestamp) as t from "
> + "\"foodmart\" where floor(\"timestamp\" to MONTH) >= '1997-04-30
> 18:30:00 UTC' order by t"
> + " limit 1";
> final String druidQueryPart1 =
> "filter\":{\"type\":\"bound\",\"dimension\":\"__time\","
> + "\"lower\":\"1997-05-01T00:00:00.000Z\",\"lowerStrict\":false,"
> +
> "\"ordering\":\"lexicographic\",\"extractionFn\":{\"type\":\"timeFormat\","
> + "\"format\":\"-MM-dd";
> final String druidQueryPart2 =
> "\"granularity\":\"month\",\"timeZone\":\"IST\","
> +
> "\"locale\":\"en-US\"}},\"dimensions\":[],\"metrics\":[],\"granularity\":\"all\"";
> CalciteAssert.that()
> .enable(enabled())
> .with(ImmutableMap.of("model", FOODMART.getPath()))
> .with(CalciteConnectionProperty.TIME_ZONE.camelName(), "IST")
> .query(sql)
> .runs()
> .queryContains(druidChecker(druidQueryPart1, druidQueryPart2))
> .returnsOrdered("T=1997-05-01 05:30:00");
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2133) Allow SqlGroupedWindowFunction to specify returnTypeInference in its constructor
[
https://issues.apache.org/jira/browse/CALCITE-2133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16327677#comment-16327677
]
Julian Hyde commented on CALCITE-2133:
--
Let's not just "drill another hole".
Can you add {{operandTypeInference}} and {{category}} to the constructor. Then
mark the other 2 constructors as deprecated.
> Allow SqlGroupedWindowFunction to specify returnTypeInference in its
> constructor
>
>
> Key: CALCITE-2133
> URL: https://issues.apache.org/jira/browse/CALCITE-2133
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.16.0
>Reporter: Shuyi Chen
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.16.0
>
>
> This is follow-up of CALCITE-1867; we need to add a new constructor to allow
> Flink to pass in the returnTypeInference parameter.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2133) Allow SqlGroupedWindowFunction to specify returnTypeInference in its constructor
[ https://issues.apache.org/jira/browse/CALCITE-2133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde updated CALCITE-2133: - Description: This is follow-up of CALCITE-1867; we need to add a new constructor to allow Flink to pass in the returnTypeInference parameter. (was: This is follow-up of [Calcite-1867|https://issues.apache.org/jira/browse/CALCITE-1867], we need toy add a new constructor to allow Flink to pass in the returnTypeInference parameter.) > Allow SqlGroupedWindowFunction to specify returnTypeInference in its > constructor > > > Key: CALCITE-2133 > URL: https://issues.apache.org/jira/browse/CALCITE-2133 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.16.0 >Reporter: Shuyi Chen >Assignee: Julian Hyde >Priority: Major > Fix For: 1.16.0 > > > This is follow-up of CALCITE-1867; we need to add a new constructor to allow > Flink to pass in the returnTypeInference parameter. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2135) Calcite wrongly validates invalid query when using aggregate function inside over clause
[
https://issues.apache.org/jira/browse/CALCITE-2135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16327561#comment-16327561
]
Julian Hyde commented on CALCITE-2135:
--
{quote}So, I'm guessing AggChecker's logic needs to be changed.
{quote}
Very likely, yes.
> Calcite wrongly validates invalid query when using aggregate function inside
> over clause
>
>
> Key: CALCITE-2135
> URL: https://issues.apache.org/jira/browse/CALCITE-2135
> Project: Calcite
> Issue Type: Bug
>Reporter: Volodymyr Tkach
>Assignee: Julian Hyde
>Priority: Major
>
> I wrote 2 tests with queries:
> 1. Inside SqlValidatorTest class:
> {noformat}
> @Test public void testAggregateInsideOverWithoutGroupByFails() {
> check("SELECT empno, SUM(empno) OVER (PARTITION BY deptno ORDER BY
> MIN(sal)) empno_sum, deptno FROM emp ");
> }
> {noformat}
> The test succeeds but hasn't, because `sal` field and others are not being
> grouped. Tested on postgress, mysql and hive dbs, all of them demand grouping.
> 2. Inside JdbcTest class, similar query:
> {noformat}
> @Test public void testOverWithoutGroupBy() {
> CalciteAssert.hr()
> .query("SELECT e.\"empid\", SUM( e.\"empid\") OVER (PARTITION
> BY e.\"deptno\" ORDER BY MIN( e.\"salary\")) avg_col0, e.\"deptno\" FROM
> \"hr\".\"emps\" as e")
> .returnsUnordered(
> "doesn't matter, execution doesn't reach here.");
> }
> {noformat}
> Results with error:
> {noformat}
> java.lang.RuntimeException: exception while executing [SELECT e."empid",
> SUM( e."empid") OVER (PARTITION BY e."deptno" ORDER BY MIN( e."salary"))
> avg_col0, e."deptno" FROM "hr"."emps" as e]
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1172)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1162)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returnsUnordered(CalciteAssert.java:1178)
> at
> org.apache.calcite.test.JdbcTest.testOverWithoutGroupBy(JdbcTest.java:4571)
> 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:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
> 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.RuntimeException: With materializationsEnabled=false,
> limit=0
> at
> org.apache.calcite.test.CalciteAssert.assertQuery(CalciteAssert.java:475)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1168)
> ... 30 more
> Caused by: java.sql.SQLException: error while executing SQL "SELECT
> e."empid", SUM( e."empid") OVER (PARTITION BY
[jira] [Commented] (CALCITE-2088) More complex end2end tests in Calcite Plus module
[
https://issues.apache.org/jira/browse/CALCITE-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16327559#comment-16327559
]
Julian Hyde commented on CALCITE-2088:
--
I have [send an email to Luis
Rocha|https://lists.apache.org/thread.html/ee96243deda52dbfec1b6e57d488f8fc9dbf23ca5f04e1bbec631776@%3Cdev.calcite.apache.org%3E]
and logged https://github.com/julianhyde/chinook-data-hsqldb/issues/1
requesting feedback.
> More complex end2end tests in Calcite Plus module
> -
>
> Key: CALCITE-2088
> URL: https://issues.apache.org/jira/browse/CALCITE-2088
> Project: Calcite
> Issue Type: Improvement
>Affects Versions: 1.16.0
>Reporter: Piotr Bojko
>Assignee: Piotr Bojko
>Priority: Major
>
> As in following correspondence - we would like to have more tests with more
> complexity. This should lead to lower regressions.
> {quote}
> Yes, please do.
> On Dec 8, 2017, at 7:13 AM, ptr.bo...@gmail.com wrote:
>
> I've taken a look into quidem.
>
> I will log jira for that and assign it to myself, ok?
>
> On Tue, Dec 5, 2017, 22:26 Julian Hyde wrote:
>
> More tests are always welcome.
>
> I would be wary of adding a new approach (assertj-db). Over time we end up
> with as many approaches as there are contributors, and so the code becomes
> hard to maintain. Consider using quidem (see QuidemTest and various .iq
> files in the code base); it combines assertion-based testing with the
> simplicity of script-based tests.
>
> This could be added to the “plus” module, where we don’t mind extra
> dependencies, and don’t mind if the test suite takes a long time.
>
> Julian
>
>
> On Dec 2, 2017, at 3:40 PM, ptr.bo...@gmail.com wrote:
>
> Hello fellow calcite dev team,
>
> I am building a database with use of calcite framework and decided that
> instead of simple unit tests I will go only with integration tests. This
> is
> due the fact that my code only glues the calcite with data and configures
> the whole thing decorating with web api and jdbc access (with avatica ;)
> ).
>
> I have some problems with calcite, possible bugs - some of them in apache
> jira for calcite logged already. Those problem are visible through my
> tests.
>
> And with that in mind I have an idea for a new maven artifact for
> calcite -
> end to end tests for an example h2 database. Database could have some
> tables with data - maybe 100k rows in all tables. Tests with assertj and
> its derivatives, something like I've done in my project - see the
> pastebin
> https://pastebin.com/raw/mevih4k6 .
>
> Such test set can help with lowering regressions establishing a common
> ground for talking about the calcite behaviour on specific cases (which
> can
> be described through end2end tests).
>
> The tech under such maven artifact can be pretty simple:
>
> - h2 as a data source, maybe some other
> - one properly complicated json calcite schema
> - some tech for populating h2 with data (just for having data with some
> descriptive language, not a binary format)
> - assertj-db for DSL in tests
>
> What do You think?
>
> Cheers,
> Pete
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2135) Calcite wrongly validates invalid query when using aggregate function inside over clause
[
https://issues.apache.org/jira/browse/CALCITE-2135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16327512#comment-16327512
]
Volodymyr Tkach commented on CALCITE-2135:
--
Checked, it has succeeded. The structure of the query is the same, but fields
names differ a little, because it is from JdbcTest class:
{noformat}
@Test public void testOverWithoutGroupBy() {
CalciteAssert.hr()
.query("SELECT e.\"empid\", SUM( e.\"empid\") OVER (PARTITION BY e.\"deptno\"
ORDER BY MIN( e.\"salary\")) avg_col0, e.\"deptno\" FROM \"hr\".\"emps\" as e
GROUP BY e.\"empid\", e.\"salary\", e.\"deptno\" ")
.returnsUnordered(
"empid=100; AVG_COL0=250; deptno=10\n" +
"empid=110; AVG_COL0=360; deptno=10\n" +
"empid=150; AVG_COL0=150; deptno=10\n" +
"empid=200; AVG_COL0=200; deptno=20");
}
{noformat}
So, I'm guessing AggChecker's logic needs to be changed.
> Calcite wrongly validates invalid query when using aggregate function inside
> over clause
>
>
> Key: CALCITE-2135
> URL: https://issues.apache.org/jira/browse/CALCITE-2135
> Project: Calcite
> Issue Type: Bug
>Reporter: Volodymyr Tkach
>Assignee: Julian Hyde
>Priority: Major
>
> I wrote 2 tests with queries:
> 1. Inside SqlValidatorTest class:
> {noformat}
> @Test public void testAggregateInsideOverWithoutGroupByFails() {
> check("SELECT empno, SUM(empno) OVER (PARTITION BY deptno ORDER BY
> MIN(sal)) empno_sum, deptno FROM emp ");
> }
> {noformat}
> The test succeeds but hasn't, because `sal` field and others are not being
> grouped. Tested on postgress, mysql and hive dbs, all of them demand grouping.
> 2. Inside JdbcTest class, similar query:
> {noformat}
> @Test public void testOverWithoutGroupBy() {
> CalciteAssert.hr()
> .query("SELECT e.\"empid\", SUM( e.\"empid\") OVER (PARTITION
> BY e.\"deptno\" ORDER BY MIN( e.\"salary\")) avg_col0, e.\"deptno\" FROM
> \"hr\".\"emps\" as e")
> .returnsUnordered(
> "doesn't matter, execution doesn't reach here.");
> }
> {noformat}
> Results with error:
> {noformat}
> java.lang.RuntimeException: exception while executing [SELECT e."empid",
> SUM( e."empid") OVER (PARTITION BY e."deptno" ORDER BY MIN( e."salary"))
> avg_col0, e."deptno" FROM "hr"."emps" as e]
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1172)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1162)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returnsUnordered(CalciteAssert.java:1178)
> at
> org.apache.calcite.test.JdbcTest.testOverWithoutGroupBy(JdbcTest.java:4571)
> 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:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
> 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
>
[jira] [Commented] (CALCITE-2088) More complex end2end tests in Calcite Plus module
[
https://issues.apache.org/jira/browse/CALCITE-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16327504#comment-16327504
]
Julian Hyde commented on CALCITE-2088:
--
Thanks for finishing this up, [~ptrbojko]. Next steps are on me. I need to
release chinook-data-hsqldb on maven central. Before I do that, as a courtesy,
I will contact [chinook|https://github.com/lerocha/chinook-database]'s author
[Luis Rocha|https://github.com/lerocha] and see whether he would like to
release it under his domain.
I will post here when I have made progress.
> More complex end2end tests in Calcite Plus module
> -
>
> Key: CALCITE-2088
> URL: https://issues.apache.org/jira/browse/CALCITE-2088
> Project: Calcite
> Issue Type: Improvement
>Affects Versions: 1.16.0
>Reporter: Piotr Bojko
>Assignee: Piotr Bojko
>Priority: Major
>
> As in following correspondence - we would like to have more tests with more
> complexity. This should lead to lower regressions.
> {quote}
> Yes, please do.
> On Dec 8, 2017, at 7:13 AM, ptr.bo...@gmail.com wrote:
>
> I've taken a look into quidem.
>
> I will log jira for that and assign it to myself, ok?
>
> On Tue, Dec 5, 2017, 22:26 Julian Hyde wrote:
>
> More tests are always welcome.
>
> I would be wary of adding a new approach (assertj-db). Over time we end up
> with as many approaches as there are contributors, and so the code becomes
> hard to maintain. Consider using quidem (see QuidemTest and various .iq
> files in the code base); it combines assertion-based testing with the
> simplicity of script-based tests.
>
> This could be added to the “plus” module, where we don’t mind extra
> dependencies, and don’t mind if the test suite takes a long time.
>
> Julian
>
>
> On Dec 2, 2017, at 3:40 PM, ptr.bo...@gmail.com wrote:
>
> Hello fellow calcite dev team,
>
> I am building a database with use of calcite framework and decided that
> instead of simple unit tests I will go only with integration tests. This
> is
> due the fact that my code only glues the calcite with data and configures
> the whole thing decorating with web api and jdbc access (with avatica ;)
> ).
>
> I have some problems with calcite, possible bugs - some of them in apache
> jira for calcite logged already. Those problem are visible through my
> tests.
>
> And with that in mind I have an idea for a new maven artifact for
> calcite -
> end to end tests for an example h2 database. Database could have some
> tables with data - maybe 100k rows in all tables. Tests with assertj and
> its derivatives, something like I've done in my project - see the
> pastebin
> https://pastebin.com/raw/mevih4k6 .
>
> Such test set can help with lowering regressions establishing a common
> ground for talking about the calcite behaviour on specific cases (which
> can
> be described through end2end tests).
>
> The tech under such maven artifact can be pretty simple:
>
> - h2 as a data source, maybe some other
> - one properly complicated json calcite schema
> - some tech for populating h2 with data (just for having data with some
> descriptive language, not a binary format)
> - assertj-db for DSL in tests
>
> What do You think?
>
> Cheers,
> Pete
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2088) More complex end2end tests in Calcite Plus module
[
https://issues.apache.org/jira/browse/CALCITE-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16327167#comment-16327167
]
Piotr Bojko commented on CALCITE-2088:
--
Switching from homemade to QuidemTest is done.
Externalize chinook to go.
> More complex end2end tests in Calcite Plus module
> -
>
> Key: CALCITE-2088
> URL: https://issues.apache.org/jira/browse/CALCITE-2088
> Project: Calcite
> Issue Type: Improvement
>Affects Versions: 1.16.0
>Reporter: Piotr Bojko
>Assignee: Piotr Bojko
>Priority: Major
>
> As in following correspondence - we would like to have more tests with more
> complexity. This should lead to lower regressions.
> {quote}
> Yes, please do.
> On Dec 8, 2017, at 7:13 AM, ptr.bo...@gmail.com wrote:
>
> I've taken a look into quidem.
>
> I will log jira for that and assign it to myself, ok?
>
> On Tue, Dec 5, 2017, 22:26 Julian Hyde wrote:
>
> More tests are always welcome.
>
> I would be wary of adding a new approach (assertj-db). Over time we end up
> with as many approaches as there are contributors, and so the code becomes
> hard to maintain. Consider using quidem (see QuidemTest and various .iq
> files in the code base); it combines assertion-based testing with the
> simplicity of script-based tests.
>
> This could be added to the “plus” module, where we don’t mind extra
> dependencies, and don’t mind if the test suite takes a long time.
>
> Julian
>
>
> On Dec 2, 2017, at 3:40 PM, ptr.bo...@gmail.com wrote:
>
> Hello fellow calcite dev team,
>
> I am building a database with use of calcite framework and decided that
> instead of simple unit tests I will go only with integration tests. This
> is
> due the fact that my code only glues the calcite with data and configures
> the whole thing decorating with web api and jdbc access (with avatica ;)
> ).
>
> I have some problems with calcite, possible bugs - some of them in apache
> jira for calcite logged already. Those problem are visible through my
> tests.
>
> And with that in mind I have an idea for a new maven artifact for
> calcite -
> end to end tests for an example h2 database. Database could have some
> tables with data - maybe 100k rows in all tables. Tests with assertj and
> its derivatives, something like I've done in my project - see the
> pastebin
> https://pastebin.com/raw/mevih4k6 .
>
> Such test set can help with lowering regressions establishing a common
> ground for talking about the calcite behaviour on specific cases (which
> can
> be described through end2end tests).
>
> The tech under such maven artifact can be pretty simple:
>
> - h2 as a data source, maybe some other
> - one properly complicated json calcite schema
> - some tech for populating h2 with data (just for having data with some
> descriptive language, not a binary format)
> - assertj-db for DSL in tests
>
> What do You think?
>
> Cheers,
> Pete
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2134) AggregateJoinTransposeRule fails in optimize phase based on CBO because of the bug in RelMdColumnUniqueness
[
https://issues.apache.org/jira/browse/CALCITE-2134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16326928#comment-16326928
]
Julian Hyde commented on CALCITE-2134:
--
We arrived at that "if" statement by trial and error during CALCITE-794. It is
somewhat arbitrary. If you can come up with something better that doesn't break
anything else or degrade performance, I'd be interested to review it.
> AggregateJoinTransposeRule fails in optimize phase based on CBO because of
> the bug in RelMdColumnUniqueness
> ---
>
> Key: CALCITE-2134
> URL: https://issues.apache.org/jira/browse/CALCITE-2134
> Project: Calcite
> Issue Type: Bug
>Reporter: jingzhang
>Assignee: Julian Hyde
>Priority: Major
> Attachments: 02-snippet.sql, 02.sql
>
>
> If runs tpch 02 query(in attachment) or snippet of 02(in attachment), the
> following exception will be thrown in AggregateJoinTranspose Rule during
> optimized phase based on VolcanoPlanner.
> {code}
> java.lang.AssertionError
> at
> org.apache.calcite.sql.SqlSplittableAggFunction$SelfSplitter.topSplit(SqlSplittableAggFunction.java:209)
> at
> org.apache.calcite.rel.rules.AggregateJoinTransposeRule.onMatch(AggregateJoinTransposeRule.java:310)
> at
> org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:212)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:650)
> {code}
> The failure is caused by the RelMdColumnUniqueness's estimation of RelSubset
> type RelNodes, which does not take Join into consideration. I don't figure
> out why only includes Aggregate, Filter, Values, TableScan, Project yet.
> {code}
> public Boolean areColumnsUnique(RelSubset rel, RelMetadataQuery mq,
> ImmutableBitSet columns, boolean ignoreNulls) {
> int nullCount = 0;
> for (RelNode rel2 : rel.getRels()) {
> if (rel2 instanceof Aggregate
> || rel2 instanceof Filter
> || rel2 instanceof Values
> || rel2 instanceof TableScan
> || simplyProjects(rel2, columns)) {
> try {
> final Boolean unique = mq.areColumnsUnique(rel2, columns,
> ignoreNulls);
> if (unique != null) {
> if (unique) {
> return true;
> }
> } else {
> ++nullCount;
> }
> } catch (CyclicMetadataException e) {
> // Ignore this relational expression; there will be non-cyclic ones
> // in this set.
> }
> }
> }
> return nullCount == 0 ? false : null;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2135) Calcite wrongly validates invalid query when using aggregate function inside over clause
[
https://issues.apache.org/jira/browse/CALCITE-2135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16326910#comment-16326910
]
Julian Hyde commented on CALCITE-2135:
--
I agree, the query is not valid, so the validator should give error.
But conversely, can you check that MIN can be used provided that there is a
GROUP BY, e.g. I think the following is valid:
{code:sql}SELECT empno,
SUM(empno) OVER (PARTITION BY deptno ORDER BY MIN(sal)) empno_sum,
deptno
FROM emp
GROUP BY empno, deptno{code}
> Calcite wrongly validates invalid query when using aggregate function inside
> over clause
>
>
> Key: CALCITE-2135
> URL: https://issues.apache.org/jira/browse/CALCITE-2135
> Project: Calcite
> Issue Type: Bug
>Reporter: Volodymyr Tkach
>Assignee: Julian Hyde
>Priority: Major
>
> I wrote 2 tests with queries:
> 1. Inside SqlValidatorTest class:
> {noformat}
> @Test public void testAggregateInsideOverWithoutGroupByFails() {
> check("SELECT empno, SUM(empno) OVER (PARTITION BY deptno ORDER BY
> MIN(sal)) empno_sum, deptno FROM emp ");
> }
> {noformat}
> The test succeeds but hasn't, because `sal` field and others are not being
> grouped. Tested on postgress, mysql and hive dbs, all of them demand grouping.
> 2. Inside JdbcTest class, similar query:
> {noformat}
> @Test public void testOverWithoutGroupBy() {
> CalciteAssert.hr()
> .query("SELECT e.\"empid\", SUM( e.\"empid\") OVER (PARTITION
> BY e.\"deptno\" ORDER BY MIN( e.\"salary\")) avg_col0, e.\"deptno\" FROM
> \"hr\".\"emps\" as e")
> .returnsUnordered(
> "doesn't matter, execution doesn't reach here.");
> }
> {noformat}
> Results with error:
> {noformat}
> java.lang.RuntimeException: exception while executing [SELECT e."empid",
> SUM( e."empid") OVER (PARTITION BY e."deptno" ORDER BY MIN( e."salary"))
> avg_col0, e."deptno" FROM "hr"."emps" as e]
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1172)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1162)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returnsUnordered(CalciteAssert.java:1178)
> at
> org.apache.calcite.test.JdbcTest.testOverWithoutGroupBy(JdbcTest.java:4571)
> 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:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
> 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.RuntimeException: With materializationsEnabled=false,
> limit=0
> at
>
[jira] [Created] (CALCITE-2136) SubQueryRemoveRule.Project generated error plan
HULING created CALCITE-2136:
---
Summary: SubQueryRemoveRule.Project generated error plan
Key: CALCITE-2136
URL: https://issues.apache.org/jira/browse/CALCITE-2136
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.4.0-incubating
Reporter: HULING
Assignee: Julian Hyde
SQL:
SELECT name, (select count(1) from EMPS t2 where t2.name = t1.name)
FROM EMPS t1
config:
SqlToRelConverter.Config.isExpand() : false
PLAN |
---
EnumerableJoin(condition=[true], joinType=[left])
TextTableScan(table=[[EMPS]], fields=[[1]])
EnumerableAggregate(group=[{}], EXPR$0=[COUNT()])
EnumerableCalc(expr#0=[\{inputs}],
{color:#FF}expr#1=[$cor0]{color}, expr#2=[$t1.NAME], expr#3=[=($t0, $t2)],
NAME=[$t0], $condition=[$t3])
TextTableScan(table=[[EMPS]], fields=[[1]])
Execution Error:
Correlation variable $cor0 should be defined
at
org.apache.calcite.adapter.enumerable.EnumerableRelImplementor.getCorrelVariableGetter(EnumerableRelImplementor.java:480)
at
org.apache.calcite.adapter.enumerable.EnumerableRelImplementor$1.apply(EnumerableRelImplementor.java:85)
at
org.apache.calcite.adapter.enumerable.EnumerableRelImplementor$1.apply(EnumerableRelImplementor.java:1)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translate0(RexToLixTranslator.java:682)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translate(RexToLixTranslator.java:221)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translate0(RexToLixTranslator.java:651)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translate(RexToLixTranslator.java:221)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translate(RexToLixTranslator.java:210)
at
org.apache.calcite.adapter.enumerable.RexImpTable.implementNullSemantics(RexImpTable.java:892)
at
org.apache.calcite.adapter.enumerable.RexImpTable.implementNullSemantics0(RexImpTable.java:845)
at
org.apache.calcite.adapter.enumerable.RexImpTable.access$0(RexImpTable.java:814)
at
org.apache.calcite.adapter.enumerable.RexImpTable$6.implement(RexImpTable.java:491)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translateCall(RexToLixTranslator.java:714)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translate0(RexToLixTranslator.java:686)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translate(RexToLixTranslator.java:221)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translate0(RexToLixTranslator.java:651)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translate(RexToLixTranslator.java:221)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translate(RexToLixTranslator.java:210)
at
org.apache.calcite.adapter.enumerable.RexImpTable$IsXxxImplementor.implement(RexImpTable.java:2118)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translateCall(RexToLixTranslator.java:714)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translate0(RexToLixTranslator.java:686)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translate(RexToLixTranslator.java:221)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translate0(RexToLixTranslator.java:651)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translate(RexToLixTranslator.java:221)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translate(RexToLixTranslator.java:210)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translateCondition(RexToLixTranslator.java:909)
at
org.apache.calcite.adapter.enumerable.EnumerableCalc.implement(EnumerableCalc.java:167)
at
org.apache.calcite.adapter.enumerable.EnumerableRelImplementor.visitChild(EnumerableRelImplementor.java:103)
at
org.apache.calcite.adapter.enumerable.EnumerableAggregate.implement(EnumerableAggregate.java:106)
at
org.apache.calcite.adapter.enumerable.EnumerableRelImplementor.visitChild(EnumerableRelImplementor.java:103)
at
org.apache.calcite.adapter.enumerable.EnumerableJoin.implement(EnumerableJoin.java:191)
at
org.apache.calcite.adapter.enumerable.EnumerableRelImplementor.visitChild(EnumerableRelImplementor.java:103)
at
org.apache.calcite.adapter.enumerable.EnumerableLimit.implement(EnumerableLimit.java:106)
at
org.apache.calcite.adapter.enumerable.EnumerableRelImplementor.implementRoot(EnumerableRelImplementor.java:108)
at
org.apache.calcite.adapter.enumerable.EnumerableInterpretable.toBindable(EnumerableInterpretable.java:92)
at
org.apache.calcite.prepare.CalcitePrepareImpl$CalcitePreparingStmt.implement(CalcitePrepareImpl.java:1262)
at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:333)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
