Re: [DISCUSS] Avatica 1.16.0 dockerfiles broken. Release 1.17.0?
The broken dockerfiles are really trivial to fix and one of the reasons I'd like to fix them and release 1.17.0 is so that I can add 1.17.0 as a test target for Avatica-Go before releasing Avatica-Go 5.0.0. In addition to fixing the dockerfiles, we should: - Agree on whether we need to release a zip archive with source files encoded using Windows line endings. If we do go down this path, I think maybe we should add "windows" to the file name of the released artifacts, so as to not confuse people. - Reorder the tasks in publishDist so that the nexus artifacts are released first before the release is tagged. Francis On 21/12/2019 6:58 am, Rui Wang wrote: I am less familiar with the broken docker stuff. Depending on how people think about it: If it is not a big problem, one thing could be done is to include it into the release notes with a section that mentions it (I have seen such practice before). -Rui On Fri, Dec 20, 2019 at 8:53 AM Stamatis Zampetakis wrote: First of all many thanks Francis for the release of 1.16.0. Being at the same time RM, contributor, and beta tester of the Gradle release build was definitely not easy :) Also special thanks to Vladimir who spend a lot of time polishing the new build system and helping in the resolution of the various problems. Last but not least, many thanks to all contributors of the 1.16.0, great work! Regarding the docker hub links, personally I don't find it a huge problem since people can still obtain and use the new release by other means. Having said that, I wouldn't mind having a 1.17.0 with the fix for docker. We could also take advantage of this, to decide if we want to do something for the build problem of the artifacts in Windows systems. Best, Stamatis On Thu, Dec 19, 2019 at 11:28 PM Francis Chuang wrote: From past experience, I think it the files should become available as long as the repository is marked as released within nexus, so this shouldn't be too much of a problem. On 20/12/2019 9:18 am, Vladimir Sitnikov wrote: AFAIK it does wait for the Nexus to release, however, I have no idea if that means the files are immediately available. Vladimir
Re: [DISCUSS] Avatica 1.16.0 dockerfiles broken. Release 1.17.0?
I am less familiar with the broken docker stuff. Depending on how people think about it: If it is not a big problem, one thing could be done is to include it into the release notes with a section that mentions it (I have seen such practice before). -Rui On Fri, Dec 20, 2019 at 8:53 AM Stamatis Zampetakis wrote: > First of all many thanks Francis for the release of 1.16.0. Being at the > same time RM, contributor, and beta tester of the Gradle release build was > definitely not easy :) > Also special thanks to Vladimir who spend a lot of time polishing the new > build system and helping in the resolution of the various problems. > Last but not least, many thanks to all contributors of the 1.16.0, great > work! > > Regarding the docker hub links, personally I don't find it a huge problem > since people can still obtain and use the new release by other means. > Having said that, I wouldn't mind having a 1.17.0 with the fix for docker. > We could also take advantage of this, to decide if we want to do something > for the build problem of the artifacts in Windows systems. > > Best, > Stamatis > > > On Thu, Dec 19, 2019 at 11:28 PM Francis Chuang > wrote: > > > From past experience, I think it the files should become available as > > long as the repository is marked as released within nexus, so this > > shouldn't be too much of a problem. > > > > On 20/12/2019 9:18 am, Vladimir Sitnikov wrote: > > > AFAIK it does wait for the Nexus to release, however, I have no idea if > > > that means the files are immediately available. > > > > > > Vladimir > > > > > >
Re: [DISCUSS] Restart the work of introducing TIME/TIMESTAMP WITH TIME ZONE types to Calcite
In general, I incline to a solution of saving timestamp with time zone by [long + a format of time zone]. The long is the epoch millis in UTC and the time zone is the original zone of the value. Using UTC epoch millis will simplify comparison and make instant semantic based functions reusable. Zone information will be useful for zone dependent functions. E.g. Extract() that extracts which "DAY" or format() that print a string which should have the right time zone included. The above is more conceptual, as many existing Java classes has saving it in that way, and implementing a class in Calcite can achieve the same goal. I think people who have more experience in Calcite runtime code might could better answer it and say which solution is better for function implementation, enumerable implementation. etc. Regarding Zhenghua's investigation of different types of time zones, in codebase I found [1], does it mean that in the past Calcite community decides to adopt the time zone format defined in [2]? [1]: https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/util/TimestampWithTimeZoneString.java#L38 [2]: https://docs.oracle.com/javase/7/docs/api/java/util/TimeZone.html -Rui On Fri, Dec 20, 2019 at 2:42 AM Zhenghua Gao wrote: > Hi > > I did some research for the storage type for TIME/TIMESTAMP WITH TIME ZONE > types, and > want to share some ideas for discussion: > >- There are three types of time zone information for both >java.sql.TimeZone and java.time.ZoneId > - Region-based time zone, such as: > Asia/Shanghai, America/Los_Angeles, etc > - Offset-based time zone, such > as: Etc/GMT, Etc/GMT+1, GMT+08:30/+08:30, etc > - Some abbreviations which have been deprecated in java.sql.TimeZone, > such as: EST, HST, ACT > > The abbreviations are always mapped to the first two types, we > can ignore them in the following discussion. > >- java.time.OffsetTime/java.time.OffsetDateTime can't be storage types >because they only covers the second type of time zone information >- So we should introduce our own internal classes to represent there >types and there are 3 choice: > - Use (int + TimeZone) to represent TIME WITH TIME ZONE, (long > +Timezone) to represent TIMESTAMP WITH TIME ZONE > - Use (int + ZoneId) to represent TIME WITH TIME ZONE, (long + > ZoneId) to represent TIMESTAMP WITH TIME ZONE > - Presto style > > Presto provide a *zone-index.properties* which > contains the fixed number key (a short value) for every supported time > zone id (a string), > and use a single long value to store the millisecond > and time zone key > > What do you think which one should be our storage solution? > > *Best Regards,* > *Zhenghua Gao* > > > On Fri, Dec 20, 2019 at 2:51 PM Rui Wang wrote: > > > Thanks Zhenghua sharing [1], which really explaining three different > > semantics of TIMESTAMP and clarified some of my long term confusion about > > TIMESTAMP. > > > > > > Julian> We need all 3, regardless of what they are called > > Can I confirm that Calcite already have the following two semantics > > support: > > > > 1. timestamp that has (number) content and “zoneless” semantics (I > believe > > it is TIMESTAMP, alternatively it might be named as > > TIMESTAMP_WITIOUT_TIME_ZONE) > > 2. a timestamp type with (number) content and “instant” semantics (which > I > > believe it is the TIME_WITH_LOCAL_TIME_ZONE > > > > > > What I am interested in is how's the current support of the first > semantic. > > And if it does not have well support, I would like to work on it to make > it > > better. (In the past I don't really find the first semantic exists in > > Calcite, maybe I have missed something). > > > > [1]: > > > > > https://docs.google.com/document/d/1gNRww9mZJcHvUDCXklzjFEQGpefsuR_akCDfWsdE35Q/edit# > > > > -Rui > > > > > > On Thu, Dec 19, 2019 at 6:27 PM Zhenghua Gao wrote: > > > > > Thanks for your comments! > > > I have opened an umbrella issue[1] to track this. > > > > > > [1] https://issues.apache.org/jira/browse/CALCITE-3611 > > > > > > *Best Regards,* > > > *Zhenghua Gao* > > > > > > > > > On Fri, Dec 20, 2019 at 4:05 AM Julian Hyde wrote: > > > > > > > It would be great to have a timestamp type with (timeZone, number) > data > > > > content, and also a timestamp type with (number) content and > “instant” > > > > semantics, in addition to the current timestamp that has (number) > > content > > > > and “zoneless” semantics. (I’m avoiding labeling these with SQL type > > > names, > > > > since this is a bit contentious. We need all 3, regardless of what > they > > > are > > > > called.) > > > > > > > > We also need improvements to the JDBC driver. Part of the reason that > > > > timestamps and time zones are so confusing in SQL is because of the > > > mapping > > > > to Java types. The new(ish) package java.time has classes that are >
Re: [ANNOUNCE] New Calcite PMC chair: Stamatis Zampetakis
Thank you guys! Your kind words in this and the other related threads have made me extremely happy and more motivated than ever. I was lucky to witness the actions of some great chairs till now so I will try to follow their example and help the project as much as I can in the year that comes. Francis was an excellent chair and for sure he will be among the first persons that I will reach out for tips :) Best, Stamatis On Fri, Dec 20, 2019 at 1:02 PM Hongze Zhang wrote: > Congratulations, Stamatis! > > > Hongze > > At 2019-12-20 18:38:12, "Jesus Camacho Rodriguez" > wrote: > >Congrats Stamatis! Well deserved! > > > >-Jesús > > > >On Thu, Dec 19, 2019 at 8:51 PM Julian Hyde wrote: > > > >> Glad to have you as the new chair, Stamatis! You have been a mature, > >> helpful and moderating voice in the community for quite some time. Well > >> deserved. > >> > >> Francis, thank you for serving as chair. Calcite became better and > >> stronger under your watch. > >> > >> I am delighted that we have had 5 chairs in the four years since Calcite > >> graduated (me, Jesus, Michael, Francis and now Stamatis). Each of the > >> chairs has been excellent, has contributed something different, and all > >> still actively involved in the community. > >> > >> Julian > >> > >> > >> > On Dec 19, 2019, at 1:32 AM, Igor Guzenko > > >> wrote: > >> > > >> > Congratulations, Stamatis! > >> > > >> > On Thu, Dec 19, 2019 at 9:04 AM Alessandro Solimando < > >> > alessandro.solima...@gmail.com> wrote: > >> > > >> >> Congratulations, Stamatis! > >> >> > >> >> Il Gio 19 Dic 2019, 07:16 Enrico Olivelli ha > >> >> scritto: > >> >> > >> >>> Congratulations Stamatis! > >> >>> > >> >>> Enrico > >> >>> > >> >>> Il gio 19 dic 2019, 04:40 Rui Wang ha > scritto: > >> >>> > >> Congratulations and Thanks Stamatis! > >> > >> > >> > >> -Rui > >> > >> On Wed, Dec 18, 2019 at 6:52 PM XING JIN > >> >>> wrote: > >> > >> > Congratulations Stamatis! > >> > > >> > -Jin > >> > > >> > Chunwei Lei 于2019年12月19日周四 上午10:33写道： > >> > > >> >> Congratulations Stamatis! > >> >> > >> >> > >> >> Best, > >> >> Chunwei > >> >> > >> >> > >> >> On Thu, Dec 19, 2019 at 9:36 AM Danny Chan > > >> wrote: > >> >> > >> >>> Congratulations Stamatis! > >> >>> > >> >>> Best, > >> >>> Danny Chan > >> >>> 在 2019年12月19日 +0800 AM7:37，dev@calcite.apache.org，写道： > >> > >> Congratulations Stamatis! > >> >>> > >> >> > >> > > >> > >> >>> > >> >> > >> > >> >
Re: [DISCUSS] Avatica 1.16.0 dockerfiles broken. Release 1.17.0?
First of all many thanks Francis for the release of 1.16.0. Being at the same time RM, contributor, and beta tester of the Gradle release build was definitely not easy :) Also special thanks to Vladimir who spend a lot of time polishing the new build system and helping in the resolution of the various problems. Last but not least, many thanks to all contributors of the 1.16.0, great work! Regarding the docker hub links, personally I don't find it a huge problem since people can still obtain and use the new release by other means. Having said that, I wouldn't mind having a 1.17.0 with the fix for docker. We could also take advantage of this, to decide if we want to do something for the build problem of the artifacts in Windows systems. Best, Stamatis On Thu, Dec 19, 2019 at 11:28 PM Francis Chuang wrote: > From past experience, I think it the files should become available as > long as the repository is marked as released within nexus, so this > shouldn't be too much of a problem. > > On 20/12/2019 9:18 am, Vladimir Sitnikov wrote: > > AFAIK it does wait for the Nexus to release, however, I have no idea if > > that means the files are immediately available. > > > > Vladimir > > >
Re: [ANNOUNCE] New Calcite PMC chair: Stamatis Zampetakis
Congratulations, Stamatis! Hongze At 2019-12-20 18:38:12, "Jesus Camacho Rodriguez" wrote: >Congrats Stamatis! Well deserved! > >-Jesús > >On Thu, Dec 19, 2019 at 8:51 PM Julian Hyde wrote: > >> Glad to have you as the new chair, Stamatis! You have been a mature, >> helpful and moderating voice in the community for quite some time. Well >> deserved. >> >> Francis, thank you for serving as chair. Calcite became better and >> stronger under your watch. >> >> I am delighted that we have had 5 chairs in the four years since Calcite >> graduated (me, Jesus, Michael, Francis and now Stamatis). Each of the >> chairs has been excellent, has contributed something different, and all >> still actively involved in the community. >> >> Julian >> >> >> > On Dec 19, 2019, at 1:32 AM, Igor Guzenko >> wrote: >> > >> > Congratulations, Stamatis! >> > >> > On Thu, Dec 19, 2019 at 9:04 AM Alessandro Solimando < >> > alessandro.solima...@gmail.com> wrote: >> > >> >> Congratulations, Stamatis! >> >> >> >> Il Gio 19 Dic 2019, 07:16 Enrico Olivelli ha >> >> scritto: >> >> >> >>> Congratulations Stamatis! >> >>> >> >>> Enrico >> >>> >> >>> Il gio 19 dic 2019, 04:40 Rui Wang ha scritto: >> >>> >> Congratulations and Thanks Stamatis! >> >> >> >> -Rui >> >> On Wed, Dec 18, 2019 at 6:52 PM XING JIN >> >>> wrote: >> >> > Congratulations Stamatis! >> > >> > -Jin >> > >> > Chunwei Lei 于2019年12月19日周四 上午10:33写道： >> > >> >> Congratulations Stamatis! >> >> >> >> >> >> Best, >> >> Chunwei >> >> >> >> >> >> On Thu, Dec 19, 2019 at 9:36 AM Danny Chan >> wrote: >> >> >> >>> Congratulations Stamatis! >> >>> >> >>> Best, >> >>> Danny Chan >> >>> 在 2019年12月19日 +0800 AM7:37，dev@calcite.apache.org，写道： >> >> Congratulations Stamatis! >> >>> >> >> >> > >> >> >>> >> >> >> >>
Re: [DISCUSS] Restart the work of introducing TIME/TIMESTAMP WITH TIME ZONE types to Calcite
Hi I did some research for the storage type for TIME/TIMESTAMP WITH TIME ZONE types, and want to share some ideas for discussion: - There are three types of time zone information for both java.sql.TimeZone and java.time.ZoneId - Region-based time zone, such as: Asia/Shanghai, America/Los_Angeles, etc - Offset-based time zone, such as: Etc/GMT, Etc/GMT+1, GMT+08:30/+08:30, etc - Some abbreviations which have been deprecated in java.sql.TimeZone, such as: EST, HST, ACT The abbreviations are always mapped to the first two types, we can ignore them in the following discussion. - java.time.OffsetTime/java.time.OffsetDateTime can't be storage types because they only covers the second type of time zone information - So we should introduce our own internal classes to represent there types and there are 3 choice: - Use (int + TimeZone) to represent TIME WITH TIME ZONE, (long +Timezone) to represent TIMESTAMP WITH TIME ZONE - Use (int + ZoneId) to represent TIME WITH TIME ZONE, (long + ZoneId) to represent TIMESTAMP WITH TIME ZONE - Presto style Presto provide a *zone-index.properties* which contains the fixed number key (a short value) for every supported time zone id (a string), and use a single long value to store the millisecond and time zone key What do you think which one should be our storage solution? *Best Regards,* *Zhenghua Gao* On Fri, Dec 20, 2019 at 2:51 PM Rui Wang wrote: > Thanks Zhenghua sharing [1], which really explaining three different > semantics of TIMESTAMP and clarified some of my long term confusion about > TIMESTAMP. > > > Julian> We need all 3, regardless of what they are called > Can I confirm that Calcite already have the following two semantics > support: > > 1. timestamp that has (number) content and “zoneless” semantics (I believe > it is TIMESTAMP, alternatively it might be named as > TIMESTAMP_WITIOUT_TIME_ZONE) > 2. a timestamp type with (number) content and “instant” semantics (which I > believe it is the TIME_WITH_LOCAL_TIME_ZONE > > > What I am interested in is how's the current support of the first semantic. > And if it does not have well support, I would like to work on it to make it > better. (In the past I don't really find the first semantic exists in > Calcite, maybe I have missed something). > > [1]: > > https://docs.google.com/document/d/1gNRww9mZJcHvUDCXklzjFEQGpefsuR_akCDfWsdE35Q/edit# > > -Rui > > > On Thu, Dec 19, 2019 at 6:27 PM Zhenghua Gao wrote: > > > Thanks for your comments! > > I have opened an umbrella issue[1] to track this. > > > > [1] https://issues.apache.org/jira/browse/CALCITE-3611 > > > > *Best Regards,* > > *Zhenghua Gao* > > > > > > On Fri, Dec 20, 2019 at 4:05 AM Julian Hyde wrote: > > > > > It would be great to have a timestamp type with (timeZone, number) data > > > content, and also a timestamp type with (number) content and “instant” > > > semantics, in addition to the current timestamp that has (number) > content > > > and “zoneless” semantics. (I’m avoiding labeling these with SQL type > > names, > > > since this is a bit contentious. We need all 3, regardless of what they > > are > > > called.) > > > > > > We also need improvements to the JDBC driver. Part of the reason that > > > timestamps and time zones are so confusing in SQL is because of the > > mapping > > > to Java types. The new(ish) package java.time has classes that are huge > > > improvements over java.sql.Timestamp. As part of this work, I would > like > > > the JDBC driver to support reading and writing java.time.Instant, > > > java.time.LocalDateTime and java.time.ZonedDateTime. > > > > > > Julian > > > > > > [1] > > > > https://docs.oracle.com/javase/8/docs/api/java/time/package-summary.html > > < > > > > https://docs.oracle.com/javase/8/docs/api/java/time/package-summary.html > > > > > > > > > > On Dec 19, 2019, at 12:43 AM, Zhenghua Gao wrote: > > > > > > > > You are right. PostgreSQL's TIMESTAMP WITH TIME ZONE has "Instant" > > > > semantics. > > > > That's the reason that CALCITE-1947 change the type as "TIMESTAMP > WITH > > > > LOCAL TIME ZONE" > > > > > > > > *Best Regards,* > > > > *Zhenghua Gao* > > > > > > > > > > > > On Thu, Dec 19, 2019 at 4:17 PM Vladimir Sitnikov < > > > > sitnikov.vladi...@gmail.com> wrote: > > > > > > > >> Zhenghua>the implementation was similar to PostgreSQL's > > > >> > > > >> PostgreSQL DB stores timestamps similar to "UNIX timestamp" (it uses > > > int8), > > > >> and it does that for both "with" and "without" time zone. > > > >> In other words, PostgreSQL cannot have "OffsetDateTime" semantics :( > > > >> > > > >> Vladimir > > > >> > > > > > > > > >
Re: [ANNOUNCE] New Calcite PMC chair: Stamatis Zampetakis
Congrats Stamatis! Well deserved! -Jesús On Thu, Dec 19, 2019 at 8:51 PM Julian Hyde wrote: > Glad to have you as the new chair, Stamatis! You have been a mature, > helpful and moderating voice in the community for quite some time. Well > deserved. > > Francis, thank you for serving as chair. Calcite became better and > stronger under your watch. > > I am delighted that we have had 5 chairs in the four years since Calcite > graduated (me, Jesus, Michael, Francis and now Stamatis). Each of the > chairs has been excellent, has contributed something different, and all > still actively involved in the community. > > Julian > > > > On Dec 19, 2019, at 1:32 AM, Igor Guzenko > wrote: > > > > Congratulations, Stamatis! > > > > On Thu, Dec 19, 2019 at 9:04 AM Alessandro Solimando < > > alessandro.solima...@gmail.com> wrote: > > > >> Congratulations, Stamatis! > >> > >> Il Gio 19 Dic 2019, 07:16 Enrico Olivelli ha > >> scritto: > >> > >>> Congratulations Stamatis! > >>> > >>> Enrico > >>> > >>> Il gio 19 dic 2019, 04:40 Rui Wang ha scritto: > >>> > Congratulations and Thanks Stamatis! > > > > -Rui > > On Wed, Dec 18, 2019 at 6:52 PM XING JIN > >>> wrote: > > > Congratulations Stamatis! > > > > -Jin > > > > Chunwei Lei 于2019年12月19日周四 上午10:33写道： > > > >> Congratulations Stamatis! > >> > >> > >> Best, > >> Chunwei > >> > >> > >> On Thu, Dec 19, 2019 at 9:36 AM Danny Chan > wrote: > >> > >>> Congratulations Stamatis! > >>> > >>> Best, > >>> Danny Chan > >>> 在 2019年12月19日 +0800 AM7:37，dev@calcite.apache.org，写道： > > Congratulations Stamatis! > >>> > >> > > > > >>> > >> > >
[jira] [Created] (CALCITE-3621) JDBC adapter can't push down sort to DB
Lei Jiang created CALCITE-3621:
--
Summary: JDBC adapter can't push down sort to DB
Key: CALCITE-3621
URL: https://issues.apache.org/jira/browse/CALCITE-3621
Project: Calcite
Issue Type: Bug
Components: jdbc-adapter
Affects Versions: 1.21.0
Reporter: Lei Jiang
Assignee: Lei Jiang
Fix For: 1.22.0
JDBC adapter can't push down sort to DB
{code:java}
select ename from scott.emp order by empno
{code}
{code:java}
PLAN=EnumerableSort(sort0=[$1], dir0=[ASC])
JdbcToEnumerableConverter
JdbcProject(ENAME=[$1], EMPNO=[$0])
JdbcTableScan(table=[[SCOTT, EMP]])
{code}
It should be:
{code:java}
PLAN=JdbcToEnumerableConverter
JdbcSort(sort0=[$1], dir0=[ASC])
JdbcProject(ENAME=[$1], EMPNO=[$0])
JdbcTableScan(table=[[SCOTT, EMP]])
{code}
I think the root cause is JdbcSortRule, it convert input's trait to "JDBC,
{color:#FF}[1]{color}". that is, input's relset will add a "JDBC, [1]"
subset. But there is nothing rule can convert that input to a rel with "JDBC,
{color:#FF}[1]{color}", so EnumerableSort win.
{code:java}
public RelNode convert(Sort sort, boolean convertInputTraits) {
final RelTraitSet traitSet = sort.getTraitSet().replace(out);
final RelNode input;
if (convertInputTraits) {
input = convert(sort.getInput(), traitSet);
} else {
input = sort.getInput();
}
return new JdbcSort(sort.getCluster(), traitSet,
input, sort.getCollation(), sort.offset, sort.fetch);
}
{code}
This is my a part of change.
{code:java}
public RelNode convert(Sort sort, boolean convertInputTraits) {
final RelTraitSet traitSet = sort.getTraitSet().replace(out);
RelTraitSet inputTraitSet = traitSet.replace(RelCollations.EMPTY);
final RelNode input;
if (convertInputTraits) {
input = convert(sort.getInput(), inputTraitSet);
} else {
input = sort.getInput();
}
return new JdbcSort(sort.getCluster(), traitSet,
input, sort.getCollation(), sort.offset, sort.fetch);
}
{code}
I have updated some classes to reslove this issue
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-3620) Remove implicit lateral operator for temporal table join
Danny Chen created CALCITE-3620: --- Summary: Remove implicit lateral operator for temporal table join Key: CALCITE-3620 URL: https://issues.apache.org/jira/browse/CALCITE-3620 Project: Calcite Issue Type: Improvement Components: core Affects Versions: 1.21.0 Reporter: Danny Chen Assignee: Danny Chen Fix For: 1.22.0 Just as what CALCITE-3603 comment addressed, LATERAL and temporal table does not have any direct relational-ship in standard SQL, we should remove that binding. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-3619) Support TIMESTAMP_WITH_TIME_ZONE in CAST
Rui Wang created CALCITE-3619: - Summary: Support TIMESTAMP_WITH_TIME_ZONE in CAST Key: CALCITE-3619 URL: https://issues.apache.org/jira/browse/CALCITE-3619 Project: Calcite Issue Type: Sub-task Reporter: Rui Wang Should figure out the CAST relationship between TIMESTAMP_WITH_TIME_ZONE and other types, and add the support accordingly. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-3618) WindowedAggRelSplitter.isDependent is incorrect
Li Xian created CALCITE-3618:
Summary: WindowedAggRelSplitter.isDependent is incorrect
Key: CALCITE-3618
URL: https://issues.apache.org/jira/browse/CALCITE-3618
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.21.0
Reporter: Li Xian
Attachments: Screen Shot 2019-12-20 at 3.49.09 PM.png
WindowedAggRelSplitter isDependent is incorrect
```
while (!dfs.isEmpty()) {
int source = dfs.pop();
if (visited.contains(source)) {
continue;
}
if (source == ordinal1) {
return true;
}
visited.add(source);
for (DefaultEdge e : graph.getOutwardEdges(source)) {
int target = (int) e.target;
if (rank.get(target) < rank.get(ordinal1)) {
dfs.push(target);
}
}
}
```
It only pushes target into dfs queue if target rank is smaller than ordinal1's
rank, which makes it impossible to find the dependency.
For SQL like
```sql
select
lag(a2, 1, 0) over (partition by "deptno" order by a1) as lagx
from
(
select
"deptno",
"salary" / "commission" as a1,
sum("commission") over ( partition by "deptno" order by "salary" /
"commission") / sum("commission") over (partition by "deptno") as a2
from
"hr"."emps"
)
```
It generates levels of exprs like the attached picture below which is
incorrect. And will cause error `Error while applying rule
ProjectToWindowRule:project`
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
