[jira] [Commented] (CALCITE-2016) ITEM + DOT operator does not work for array
[
https://issues.apache.org/jira/browse/CALCITE-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16252871#comment-16252871
]
Shuyi Chen commented on CALCITE-2016:
-
Hi [~julianhyde], do you think if we can get this in 1.15 release?
> ITEM + DOT operator does not work for array
> ---
>
> Key: CALCITE-2016
> URL: https://issues.apache.org/jira/browse/CALCITE-2016
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Shuyi Chen
>Assignee: Julian Hyde
>
> Query with ITEM + DOT operator for array does not parse. Below is an example
> query and its stack trace.
> *Query*: {code}SELECT employees[1].empno from dept_nested{code}
> *Stacktrace*:
> {noformat}
> java.lang.RuntimeException: Error while parsing query: SELECT
> employees[1].empno from dept_nested
> at
> org.apache.calcite.sql.test.SqlTesterImpl.parseAndValidate(SqlTesterImpl.java:161)
> at
> org.apache.calcite.sql.test.SqlTesterImpl.getResultType(SqlTesterImpl.java:148)
> at
> org.apache.calcite.sql.test.SqlTesterImpl.checkResultType(SqlTesterImpl.java:204)
> at
> org.apache.calcite.test.SqlValidatorTestCase$Sql.type(SqlValidatorTestCase.java:603)
> at
> org.apache.calcite.test.SqlValidatorTest.testRecordTypeElided(SqlValidatorTest.java:7715)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:117)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:42)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:262)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:84)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
> Caused by: org.apache.calcite.sql.parser.SqlParseException: Encountered "."
> at line 1, column 20.
> Was expecting one of:
>
> "ORDER" ...
> "LIMIT" ...
> "OFFSET" ...
> "FETCH" ...
> "FROM" ...
> "," ...
> "AS" ...
> ...
> ...
> ...
> ...
> ...
> "UNION" ...
> "INTERSECT" ...
> "EXCEPT" ...
> "MINUS" ...
> "NOT" ...
> "IN" ...
> "BETWEEN" ...
> "LIKE" ...
> "SIMILAR" ...
> "=" ...
> ">" ...
> "<" ...
> "<=" ...
> ">=" ...
> "<>" ...
> "!=" ...
> "+" ...
> "-" ...
> "*" ...
> "/" ...
> "||" ...
> "AND" ...
> "OR" ...
> "IS" ...
> "MEMBER" ...
> "SUBMULTISET" ...
> "CONTAINS" ...
> "OVERLAPS" ...
> "EQUALS" ...
> "PRECEDES" ...
> "SUCCEEDS" ...
> "MULTISET" ...
> "[" ...
>
> at
> org.apache.calcite.sql.parser.impl.SqlParserImpl.convertException(SqlParserImpl.java:349)
> at
> org.apache.calcite.sql.parser.impl.SqlParserImpl.normalizeException(SqlParserImpl.java:130)
> at
>
[jira] [Commented] (CALCITE-707) Built-in support for simple DDL statements
[ https://issues.apache.org/jira/browse/CALCITE-707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16252870#comment-16252870 ] Shuyi Chen commented on CALCITE-707: Do you think this can make it to the 1.15 release? > Built-in support for simple DDL statements > -- > > Key: CALCITE-707 > URL: https://issues.apache.org/jira/browse/CALCITE-707 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Julian Hyde > > I would like Calcite to support simple DDL. > DDL (and other commands such as KILL STATEMENT) make it possible to do a wide > range of operations over a REST or JDBC interface. We can't expect everything > do be done locally, using Java method calls. > I expect that projects that use Calcite will define their own DDL. (In fact > Drill and Phoenix already do; see PHOENIX-1706.) Those projects are very > likely to have their own variations on CREATE TABLE etc. so they will want to > extend the parser. What I did in Phoenix (which was in turn adapted from > Drill) is a model that other projects can follow. > But the base Calcite project should have CREATE TABLE, DROP TABLE, CREATE > SCHEMA, DROP SCHEMA, CREATE [ OR REPLACE ] VIEW etc. There will be an AST > (extending SqlNode) for each of these commands, and a command-handler. Each > project that uses Calcite could extend those > ASTs, but it would be fine if it built its own AST and command-handler. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (CALCITE-2052) Remove SQL code style from MV documentation
[ https://issues.apache.org/jira/browse/CALCITE-2052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jesus Camacho Rodriguez resolved CALCITE-2052. -- Resolution: Fixed Fixed in http://git-wip-us.apache.org/repos/asf/calcite/commit/3e587afb0. > Remove SQL code style from MV documentation > --- > > Key: CALCITE-2052 > URL: https://issues.apache.org/jira/browse/CALCITE-2052 > Project: Calcite > Issue Type: Improvement >Reporter: Jesus Camacho Rodriguez >Assignee: Jesus Camacho Rodriguez > Fix For: 1.15.0 > > > As it is not rendered properly in website. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CALCITE-2052) Remove SQL code style from MV documentation
Jesus Camacho Rodriguez created CALCITE-2052: Summary: Remove SQL code style from MV documentation Key: CALCITE-2052 URL: https://issues.apache.org/jira/browse/CALCITE-2052 Project: Calcite Issue Type: Improvement Reporter: Jesus Camacho Rodriguez Assignee: Jesus Camacho Rodriguez Fix For: 1.15.0 As it is not rendered properly in website. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-2051) Rules using Aggregate might check for simple grouping sets incorrectly
[
https://issues.apache.org/jira/browse/CALCITE-2051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16252743#comment-16252743
]
Jesus Camacho Rodriguez commented on CALCITE-2051:
--
[~julianhyde], I have created a PR with the changes to the rules that contain
that same snippet:
https://github.com/apache/calcite/pull/566
We were hitting the issue in Hive with a query {{... group by (a, b) grouping
sets (a) ...}}. Thus, you end up with grouping sets with a single set that is
not equal to the set in the group by clause. This is possible in Hive, but I
think it is not standard SQL, and I have not been able to reproduce it in
Calcite. The {{induce}} method in {{Aggregate}} class takes this into account:
https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/rel/core/Aggregate.java#L470
That is the reason why this change fixes the issue.
> Rules using Aggregate might check for simple grouping sets incorrectly
> --
>
> Key: CALCITE-2051
> URL: https://issues.apache.org/jira/browse/CALCITE-2051
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Jesus Camacho Rodriguez
>Assignee: Jesus Camacho Rodriguez
>Priority: Critical
> Fix For: 1.15.0
>
>
> CALCITE-1069 removed the indicator columns for Aggregate operators. In some
> places, the indicator boolean check was replaced by the following check:
> {{aggregate.getGroupSets().size() > 1}}. However, that check is incomplete,
> it should have been replaced by {{aggregate.getGroupType() != Group.SIMPLE}}.
> For instance :
> https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/rel/rules/AggregateProjectMergeRule.java#L91
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (CALCITE-2016) ITEM + DOT operator does not work for array
[
https://issues.apache.org/jira/browse/CALCITE-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16252733#comment-16252733
]
Shuyi Chen edited comment on CALCITE-2016 at 11/15/17 12:16 AM:
[~julianhyde], I've updated the PR to change the parser to parse subfield as
SqlIdentifier, and added a test to make sure that referring to an unknown field
gives an error in SqlValidatorTest. Can you take another look at the
PR[https://github.com/apache/calcite/pull/557]? Thanks.
was (Author: suez1224):
[~julianhyde], I've updated the PR to change the parser to parse subfield as
SqlIdentifier, and added a test to make sure that referring to an unknown field
gives an error in SqlValidatorTest. Can you take another look at the
[https://github.com/apache/calcite/pull/557]? Thanks.
> ITEM + DOT operator does not work for array
> ---
>
> Key: CALCITE-2016
> URL: https://issues.apache.org/jira/browse/CALCITE-2016
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Shuyi Chen
>Assignee: Julian Hyde
>
> Query with ITEM + DOT operator for array does not parse. Below is an example
> query and its stack trace.
> *Query*: {code}SELECT employees[1].empno from dept_nested{code}
> *Stacktrace*:
> {noformat}
> java.lang.RuntimeException: Error while parsing query: SELECT
> employees[1].empno from dept_nested
> at
> org.apache.calcite.sql.test.SqlTesterImpl.parseAndValidate(SqlTesterImpl.java:161)
> at
> org.apache.calcite.sql.test.SqlTesterImpl.getResultType(SqlTesterImpl.java:148)
> at
> org.apache.calcite.sql.test.SqlTesterImpl.checkResultType(SqlTesterImpl.java:204)
> at
> org.apache.calcite.test.SqlValidatorTestCase$Sql.type(SqlValidatorTestCase.java:603)
> at
> org.apache.calcite.test.SqlValidatorTest.testRecordTypeElided(SqlValidatorTest.java:7715)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:117)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:42)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:262)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:84)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
> Caused by: org.apache.calcite.sql.parser.SqlParseException: Encountered "."
> at line 1, column 20.
> Was expecting one of:
>
> "ORDER" ...
> "LIMIT" ...
> "OFFSET" ...
> "FETCH" ...
> "FROM" ...
> "," ...
> "AS" ...
> ...
> ...
> ...
> ...
> ...
> "UNION" ...
> "INTERSECT" ...
> "EXCEPT" ...
> "MINUS" ...
> "NOT" ...
> "IN" ...
> "BETWEEN" ...
> "LIKE" ...
> "SIMILAR" ...
> "=" ...
> ">" ...
> "<" ...
> "<=" ...
> ">=" ...
> "<>" ...
> "!=" ...
[jira] [Comment Edited] (CALCITE-2016) ITEM + DOT operator does not work for array
[
https://issues.apache.org/jira/browse/CALCITE-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16252733#comment-16252733
]
Shuyi Chen edited comment on CALCITE-2016 at 11/15/17 12:16 AM:
[~julianhyde], I've updated the PR to change the parser to parse subfield as
SqlIdentifier, and added a test to make sure that referring to an unknown field
gives an error in SqlValidatorTest. Can you take another look at the
PR([https://github.com/apache/calcite/pull/557])? Thanks.
was (Author: suez1224):
[~julianhyde], I've updated the PR to change the parser to parse subfield as
SqlIdentifier, and added a test to make sure that referring to an unknown field
gives an error in SqlValidatorTest. Can you take another look at the
PR[https://github.com/apache/calcite/pull/557]? Thanks.
> ITEM + DOT operator does not work for array
> ---
>
> Key: CALCITE-2016
> URL: https://issues.apache.org/jira/browse/CALCITE-2016
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Shuyi Chen
>Assignee: Julian Hyde
>
> Query with ITEM + DOT operator for array does not parse. Below is an example
> query and its stack trace.
> *Query*: {code}SELECT employees[1].empno from dept_nested{code}
> *Stacktrace*:
> {noformat}
> java.lang.RuntimeException: Error while parsing query: SELECT
> employees[1].empno from dept_nested
> at
> org.apache.calcite.sql.test.SqlTesterImpl.parseAndValidate(SqlTesterImpl.java:161)
> at
> org.apache.calcite.sql.test.SqlTesterImpl.getResultType(SqlTesterImpl.java:148)
> at
> org.apache.calcite.sql.test.SqlTesterImpl.checkResultType(SqlTesterImpl.java:204)
> at
> org.apache.calcite.test.SqlValidatorTestCase$Sql.type(SqlValidatorTestCase.java:603)
> at
> org.apache.calcite.test.SqlValidatorTest.testRecordTypeElided(SqlValidatorTest.java:7715)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:117)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:42)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:262)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:84)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
> Caused by: org.apache.calcite.sql.parser.SqlParseException: Encountered "."
> at line 1, column 20.
> Was expecting one of:
>
> "ORDER" ...
> "LIMIT" ...
> "OFFSET" ...
> "FETCH" ...
> "FROM" ...
> "," ...
> "AS" ...
> ...
> ...
> ...
> ...
> ...
> "UNION" ...
> "INTERSECT" ...
> "EXCEPT" ...
> "MINUS" ...
> "NOT" ...
> "IN" ...
> "BETWEEN" ...
> "LIKE" ...
> "SIMILAR" ...
> "=" ...
> ">" ...
> "<" ...
> "<=" ...
> ">=" ...
> "<>" ...
> "!="
[jira] [Comment Edited] (CALCITE-2051) Rules using Aggregate might check for simple grouping sets incorrectly
[
https://issues.apache.org/jira/browse/CALCITE-2051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16252562#comment-16252562
]
Jesus Camacho Rodriguez edited comment on CALCITE-2051 at 11/14/17 11:59 PM:
-
Fwiw, the query was grouping by a set of columns and it contained a unique
grouping set with a subset of the grouping columns.
was (Author: jcamachorodriguez):
Fwiw, the query was grouping by a set of columns and it contained a unique
grouping set with a subset of of the grouping columns.
> Rules using Aggregate might check for simple grouping sets incorrectly
> --
>
> Key: CALCITE-2051
> URL: https://issues.apache.org/jira/browse/CALCITE-2051
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Jesus Camacho Rodriguez
>Assignee: Jesus Camacho Rodriguez
>Priority: Critical
> Fix For: 1.15.0
>
>
> CALCITE-1069 removed the indicator columns for Aggregate operators. In some
> places, the indicator boolean check was replaced by the following check:
> {{aggregate.getGroupSets().size() > 1}}. However, that check is incomplete,
> it should have been replaced by {{aggregate.getGroupType() != Group.SIMPLE}}.
> For instance :
> https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/rel/rules/AggregateProjectMergeRule.java#L91
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (CALCITE-2012) Replace LocalInterval by Interval in Druid adapter
[ https://issues.apache.org/jira/browse/CALCITE-2012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jesus Camacho Rodriguez resolved CALCITE-2012. -- Resolution: Fixed [~julianhyde], patch was in fact ready. Fixed in http://git-wip-us.apache.org/repos/asf/calcite/commit/20ade9d. > Replace LocalInterval by Interval in Druid adapter > -- > > Key: CALCITE-2012 > URL: https://issues.apache.org/jira/browse/CALCITE-2012 > Project: Calcite > Issue Type: Task > Components: druid >Affects Versions: 1.14.0 >Reporter: Jesus Camacho Rodriguez >Assignee: Jesus Camacho Rodriguez > Fix For: 1.15.0 > > > CALCITE-1617 introduced LocalInterval as a proper way to close the gap > between the semantics of SQL timestamp type and Druid instants. > After that, CALCITE-1947 introduced 'timestamp with local time zone' type in > Calcite and mapped the Druid time column to this type. Thus, we do not need > anymore the LocalInterval class and we can use Joda Interval, since the > column represents an Instant rather than a LocalDateTime. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-2051) Rules using Aggregate might check for simple grouping sets incorrectly
[
https://issues.apache.org/jira/browse/CALCITE-2051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16252562#comment-16252562
]
Jesus Camacho Rodriguez commented on CALCITE-2051:
--
Fwiw, the query was grouping by a set of columns and it contained a unique
grouping set with a subset of of the grouping columns.
> Rules using Aggregate might check for simple grouping sets incorrectly
> --
>
> Key: CALCITE-2051
> URL: https://issues.apache.org/jira/browse/CALCITE-2051
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Jesus Camacho Rodriguez
>Assignee: Jesus Camacho Rodriguez
>Priority: Critical
> Fix For: 1.15.0
>
>
> CALCITE-1069 removed the indicator columns for Aggregate operators. In some
> places, the indicator boolean check was replaced by the following check:
> {{aggregate.getGroupSets().size() > 1}}. However, that check is incomplete,
> it should have been replaced by {{aggregate.getGroupType() != Group.SIMPLE}}.
> For instance :
> https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/rel/rules/AggregateProjectMergeRule.java#L91
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (CALCITE-2051) Rules using Aggregate might check for simple grouping sets incorrectly
[
https://issues.apache.org/jira/browse/CALCITE-2051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jesus Camacho Rodriguez updated CALCITE-2051:
-
Description:
CALCITE-1069 removed the indicator columns for Aggregate operators. In some
places, the indicator boolean check was replaced by the following check:
{{aggregate.getGroupSets().size() > 1}}. However, that check is incomplete, it
should have been replaced by {{aggregate.getGroupType() != Group.SIMPLE}}.
For instance :
https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/rel/rules/AggregateProjectMergeRule.java#L91
was:
CALCITE-1069 removed the indicator columns for Aggregate operators. In some
places, the indicator boolean check was replaced by the following check:
{{aggregate.getGroupSets().size() > 1}}. However, that check is incomplete, it
should have been replace by {{aggregate.getGroupType() != Group.SIMPLE}}.
For instance :
https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/rel/rules/AggregateProjectMergeRule.java#L91
> Rules using Aggregate might check for simple grouping sets incorrectly
> --
>
> Key: CALCITE-2051
> URL: https://issues.apache.org/jira/browse/CALCITE-2051
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Jesus Camacho Rodriguez
>Assignee: Jesus Camacho Rodriguez
>Priority: Critical
> Fix For: 1.15.0
>
>
> CALCITE-1069 removed the indicator columns for Aggregate operators. In some
> places, the indicator boolean check was replaced by the following check:
> {{aggregate.getGroupSets().size() > 1}}. However, that check is incomplete,
> it should have been replaced by {{aggregate.getGroupType() != Group.SIMPLE}}.
> For instance :
> https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/rel/rules/AggregateProjectMergeRule.java#L91
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-2051) Rules using Aggregate might check for simple grouping sets incorrectly
[
https://issues.apache.org/jira/browse/CALCITE-2051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16252536#comment-16252536
]
Julian Hyde commented on CALCITE-2051:
--
Is there a SQL query that illustrates this problem?
> Rules using Aggregate might check for simple grouping sets incorrectly
> --
>
> Key: CALCITE-2051
> URL: https://issues.apache.org/jira/browse/CALCITE-2051
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Jesus Camacho Rodriguez
>Assignee: Jesus Camacho Rodriguez
>Priority: Critical
> Fix For: 1.15.0
>
>
> CALCITE-1069 removed the indicator columns for Aggregate operators. In some
> places, the indicator boolean check was replaced by the following check:
> {{aggregate.getGroupSets().size() > 1}}. However, that check is incomplete,
> it should have been replace by {{aggregate.getGroupType() == Group.SIMPLE}}.
> For instance :
> https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/rel/rules/AggregateProjectMergeRule.java#L91
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (CALCITE-2051) Rules using Aggregate might check for simple grouping sets incorrectly
Jesus Camacho Rodriguez created CALCITE-2051:
Summary: Rules using Aggregate might check for simple grouping
sets incorrectly
Key: CALCITE-2051
URL: https://issues.apache.org/jira/browse/CALCITE-2051
Project: Calcite
Issue Type: Bug
Components: core
Reporter: Jesus Camacho Rodriguez
Assignee: Jesus Camacho Rodriguez
Priority: Critical
Fix For: 1.15.0
CALCITE-1069 removed the indicator columns for Aggregate operators. In some
places, the indicator boolean check was replaced by the following check:
{{aggregate.getGroupSets().size() > 1}}. However, that check is incomplete, it
should have been replace by {{aggregate.getGroupType() == Group.SIMPLE}}.
For instance :
https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/rel/rules/AggregateProjectMergeRule.java#L91
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (CALCITE-2041) Adding the ability to turn off nullability matching for ReduceExpressionsRule
[
https://issues.apache.org/jira/browse/CALCITE-2041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jesus Camacho Rodriguez updated CALCITE-2041:
-
Fix Version/s: 1.15.0
> Adding the ability to turn off nullability matching for ReduceExpressionsRule
> -
>
> Key: CALCITE-2041
> URL: https://issues.apache.org/jira/browse/CALCITE-2041
> Project: Calcite
> Issue Type: Bug
>Reporter: slim bouguerra
>Assignee: Julian Hyde
> Fix For: 1.15.0
>
>
> In some cases, the user needs to select whether or not to add casts that
> match nullability.
> One of the motivations behind this is to avoid unnecessary casts like the
> following example.
> original filter
> {code}
> OR(AND(>=($0, CAST(_UTF-16LE'2010-01-01 00:00:00
> UTC'):TIMESTAMP_WITH_LOCAL_TIME_ZONE(15)), <=($0, CAST(_UTF-16LE'2012-03-01
> 00:00:00 UTC'):TIMESTAMP_WITH_LOCAL_TIME_ZONE(15
> {code}
> the optimized expression with matching nullability
> {code}
> OR(AND(CAST(>=($0, 2010-01-01 00:00:00)):BOOLEAN, CAST(<=($0, 2012-03-01
> 00:00:00)):BOOLEAN))
> {code}
> As you can see this extra cast gets into the way of following plan
> optimization steps.
> The desired expression can be obtained by turning off the nullability
> matching.
> {code}
> OR(AND(>=($0, 2010-01-01 00:00:00), <=($0, 2012-03-01 00:00:00)))
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (CALCITE-2050) Exception when pushing postaggregates into Druid
[
https://issues.apache.org/jira/browse/CALCITE-2050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jesus Camacho Rodriguez updated CALCITE-2050:
-
Fix Version/s: 1.15.0
> Exception when pushing postaggregates into Druid
>
>
> Key: CALCITE-2050
> URL: https://issues.apache.org/jira/browse/CALCITE-2050
> Project: Calcite
> Issue Type: Bug
> Components: druid
>Reporter: Jesus Camacho Rodriguez
>Assignee: Jesus Camacho Rodriguez
> Fix For: 1.15.0
>
>
> After Calcite is upgraded to 1.14 and the rule to push post-aggregations to
> Druid is enabled, the following query will fail:
> {code}
> EXPLAIN
> SELECT language, robot, sum(added) - sum(delta) AS a
> FROM druid_table_1
> WHERE extract (week from `__time`) IN (10,11)
> AND robot='Bird Call'
> GROUP BY language, robot;
> {code}
> The error we get is the following:
> {code}
> Cannot add expression of different type to set:
> set type is RecordType(VARCHAR(2147483647) CHARACTER SET "UTF-16LE" COLLATE
> "ISO-8859-1$en_US$primary" language, VARCHAR(2147483647) CHARACTER SET
> "UTF-16LE" COLLATE "ISO-8859-1$en_US$primary" robot, DOUBLE a) NOT NULL
> expression type is RecordType(VARCHAR(2147483647) CHARACTER SET "UTF-16LE"
> COLLATE "ISO-8859-1$en_US$primary" language, DOUBLE postagg#0) NOT NULL
> set is
> rel#1507:HiveProject.HIVE.[](input=HepRelVertex#1514,language=$0,robot=CAST(_UTF-16LE'Bird
> Call'):VARCHAR(2147483647) CHARACTER SET "UTF-16LE" COLLATE
> "ISO-8859-1$en_US$primary",a=-($1, $2))
> expression is DruidQuery#1516
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Moved] (CALCITE-2050) Exception when pushing postaggregates into Druid
[
https://issues.apache.org/jira/browse/CALCITE-2050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jesus Camacho Rodriguez moved HIVE-18065 to CALCITE-2050:
-
Affects Version/s: (was: 3.0.0)
Target Version/s: (was: 3.0.0)
Component/s: (was: Druid integration)
druid
Workflow: jira (was: no-reopen-closed, patch-avail)
Key: CALCITE-2050 (was: HIVE-18065)
Project: Calcite (was: Hive)
> Exception when pushing postaggregates into Druid
>
>
> Key: CALCITE-2050
> URL: https://issues.apache.org/jira/browse/CALCITE-2050
> Project: Calcite
> Issue Type: Bug
> Components: druid
>Reporter: Jesus Camacho Rodriguez
>Assignee: Jesus Camacho Rodriguez
> Fix For: 1.15.0
>
>
> After Calcite is upgraded to 1.14 and the rule to push post-aggregations to
> Druid is enabled, the following query will fail:
> {code}
> EXPLAIN
> SELECT language, robot, sum(added) - sum(delta) AS a
> FROM druid_table_1
> WHERE extract (week from `__time`) IN (10,11)
> AND robot='Bird Call'
> GROUP BY language, robot;
> {code}
> The error we get is the following:
> {code}
> Cannot add expression of different type to set:
> set type is RecordType(VARCHAR(2147483647) CHARACTER SET "UTF-16LE" COLLATE
> "ISO-8859-1$en_US$primary" language, VARCHAR(2147483647) CHARACTER SET
> "UTF-16LE" COLLATE "ISO-8859-1$en_US$primary" robot, DOUBLE a) NOT NULL
> expression type is RecordType(VARCHAR(2147483647) CHARACTER SET "UTF-16LE"
> COLLATE "ISO-8859-1$en_US$primary" language, DOUBLE postagg#0) NOT NULL
> set is
> rel#1507:HiveProject.HIVE.[](input=HepRelVertex#1514,language=$0,robot=CAST(_UTF-16LE'Bird
> Call'):VARCHAR(2147483647) CHARACTER SET "UTF-16LE" COLLATE
> "ISO-8859-1$en_US$primary",a=-($1, $2))
> expression is DruidQuery#1516
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-2041) Adding the ability to turn off nullability matching for ReduceExpressionsRule
[
https://issues.apache.org/jira/browse/CALCITE-2041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16252187#comment-16252187
]
Jesus Camacho Rodriguez commented on CALCITE-2041:
--
[~julianhyde], we have been trying to create tests for this issue
(ReduceExpressionsRule#FILTER_INSTANCE is disabled by default so we tried to
use RelOptRulesTest), but we could not come up with same plan as in Hive. Do
you have any other suggestions? [~bslim] has been testing the rule in Hive with
the change his proposed change (HIVE-17871) and everything is working as
expected and without issues, so I would like to check in the patch if possible.
To be clear, the proposed change is quite straightforward: it exposes a flag to
match to indicate whether reduce expressions should match nullability or not
when expressions are simplified (by default it is _true_, so current behavior
is preserved).
> Adding the ability to turn off nullability matching for ReduceExpressionsRule
> -
>
> Key: CALCITE-2041
> URL: https://issues.apache.org/jira/browse/CALCITE-2041
> Project: Calcite
> Issue Type: Bug
>Reporter: slim bouguerra
>Assignee: Julian Hyde
>
> In some cases, the user needs to select whether or not to add casts that
> match nullability.
> One of the motivations behind this is to avoid unnecessary casts like the
> following example.
> original filter
> {code}
> OR(AND(>=($0, CAST(_UTF-16LE'2010-01-01 00:00:00
> UTC'):TIMESTAMP_WITH_LOCAL_TIME_ZONE(15)), <=($0, CAST(_UTF-16LE'2012-03-01
> 00:00:00 UTC'):TIMESTAMP_WITH_LOCAL_TIME_ZONE(15
> {code}
> the optimized expression with matching nullability
> {code}
> OR(AND(CAST(>=($0, 2010-01-01 00:00:00)):BOOLEAN, CAST(<=($0, 2012-03-01
> 00:00:00)):BOOLEAN))
> {code}
> As you can see this extra cast gets into the way of following plan
> optimization steps.
> The desired expression can be obtained by turning off the nullability
> matching.
> {code}
> OR(AND(>=($0, 2010-01-01 00:00:00), <=($0, 2012-03-01 00:00:00)))
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-2044) Tweak cost of BindableTableScan to make sure Project is pushed through Aggregate
[
https://issues.apache.org/jira/browse/CALCITE-2044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16252077#comment-16252077
]
Julian Hyde commented on CALCITE-2044:
--
{{RelDataTypeFactory.builder()}} isn't actually deprecated. It just has the
annotation {{@SuppressWarnings("deprecation")}} to stop the compiler
complaining that we are using {{FieldInfoBuilder}}, which was deprecated as of
CALCITE-1929. I wanted to change the return type to
{{RelDataTypeFactory.Builder}}, which is {{FieldInfoBuilder}}'s base class and
is not deprecated, but I could not do so due to binary compatibility.
So yes, use {{RelDataTypeFactory.builder()}}. I will make that change for you.
> Tweak cost of BindableTableScan to make sure Project is pushed through
> Aggregate
>
>
> Key: CALCITE-2044
> URL: https://issues.apache.org/jira/browse/CALCITE-2044
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Luis Fernando Kauer
>Assignee: Julian Hyde
>Priority: Minor
>
> Similar to [CALCITE-1876].
> Projects are not pushed to BindableTableScan when using
> ProjectableFilterableTable with aggregate functions.
> The reason is that the cost of BindableTableScan does not use projects (and
> filters), so the planner chooses a plan with Project node removed by
> ProjectRemoveRule.
> By tweaking the cost to use the number of used projects solved the problem.
> Any suggestion on the cost formula to take both projects and filters into
> account?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-2012) Replace LocalInterval by Interval in Druid adapter
[ https://issues.apache.org/jira/browse/CALCITE-2012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16252069#comment-16252069 ] Julian Hyde commented on CALCITE-2012: -- [~jcamachorodriguez], Is this PR ready for review? Do you think this will be ready for code freeze on Nov 27? > Replace LocalInterval by Interval in Druid adapter > -- > > Key: CALCITE-2012 > URL: https://issues.apache.org/jira/browse/CALCITE-2012 > Project: Calcite > Issue Type: Task > Components: druid >Affects Versions: 1.14.0 >Reporter: Jesus Camacho Rodriguez >Assignee: Jesus Camacho Rodriguez > Fix For: 1.15.0 > > > CALCITE-1617 introduced LocalInterval as a proper way to close the gap > between the semantics of SQL timestamp type and Druid instants. > After that, CALCITE-1947 introduced 'timestamp with local time zone' type in > Calcite and mapped the Druid time column to this type. Thus, we do not need > anymore the LocalInterval class and we can use Joda Interval, since the > column represents an Instant rather than a LocalDateTime. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (CALCITE-2049) Release Calcite 1.15.0
[ https://issues.apache.org/jira/browse/CALCITE-2049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde updated CALCITE-2049: - Fix Version/s: 1.15.0 > Release Calcite 1.15.0 > -- > > Key: CALCITE-2049 > URL: https://issues.apache.org/jira/browse/CALCITE-2049 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Julian Hyde > Fix For: 1.15.0 > > > Release Calcite 1.15.0. > Target date for RC and vote is Nov 27th (just after Thanksgiving), with > release date possibly first week of December. I volunteer to be release > manager. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CALCITE-2049) Release Calcite 1.15.0
Julian Hyde created CALCITE-2049: Summary: Release Calcite 1.15.0 Key: CALCITE-2049 URL: https://issues.apache.org/jira/browse/CALCITE-2049 Project: Calcite Issue Type: Bug Reporter: Julian Hyde Assignee: Julian Hyde Release Calcite 1.15.0. Target date for RC and vote is Nov 27th (just after Thanksgiving), with release date possibly first week of December. I volunteer to be release manager. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (CALCITE-2018) Queries failed with AssertionError: rel has lower cost than best cost of subset
[
https://issues.apache.org/jira/browse/CALCITE-2018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-2018:
-
Fix Version/s: 1.15.0
> Queries failed with AssertionError: rel has lower cost than best cost of
> subset
> ---
>
> Key: CALCITE-2018
> URL: https://issues.apache.org/jira/browse/CALCITE-2018
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.13.0
>Reporter: Volodymyr Vysotskyi
>Assignee: Julian Hyde
> Fix For: 1.15.0
>
>
> *Problem description*
> When rootLogger level is DEBUG, unit tests
> * MaterializationTest.testMaterializationSubstitution2
> * MaterializationTest.testJoinMaterializationUKFK8
> * MaterializationTest.testJoinMaterializationUKFK6
> * JdbcTest.testWhereNot
> unit tests are failed with error AssertionError: rel has lower cost than best
> cost of subset.
> Full stack trace for test
> {{MaterializationTest.testMaterializationSubstitution2}}:
> {noformat}
> java.lang.AssertionError: rel
> [rel#245:EnumerableUnion.ENUMERABLE.[](input#0=rel#246:Subset#5.ENUMERABLE.[],input#1=rel#239:Subset#6.ENUMERABLE.[0],all=true)]
> has lower cost {14.0 rows, 19.0 cpu, 0.0 io} than best cost {15.0 rows, 20.0
> cpu, 0.0 io} of subset [rel#243:Subset#7.ENUMERABLE.[]]
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.validate(VolcanoPlanner.java:906)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.register(VolcanoPlanner.java:866)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.ensureRegistered(VolcanoPlanner.java:883)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.ensureRegistered(VolcanoPlanner.java:101)
> at
> org.apache.calcite.rel.AbstractRelNode.onRegister(AbstractRelNode.java:336)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.registerImpl(VolcanoPlanner.java:1495)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.register(VolcanoPlanner.java:863)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.ensureRegistered(VolcanoPlanner.java:883)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.ensureRegistered(VolcanoPlanner.java:1766)
> at
> org.apache.calcite.plan.volcano.VolcanoRuleCall.transformTo(VolcanoRuleCall.java:135)
> at
> org.apache.calcite.plan.RelOptRuleCall.transformTo(RelOptRuleCall.java:234)
> at
> org.apache.calcite.rel.rules.FilterProjectTransposeRule.onMatch(FilterProjectTransposeRule.java:143)
> at
> org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:212)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:650)
> at org.apache.calcite.tools.Programs$5.run(Programs.java:326)
> at
> org.apache.calcite.tools.Programs$SequenceProgram.run(Programs.java:387)
> at org.apache.calcite.prepare.Prepare.optimize(Prepare.java:187)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:318)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:229)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:786)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:640)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:610)
> at org.apache.calcite.schema.Schemas.prepare(Schemas.java:346)
> at
> org.apache.calcite.materialize.MaterializationService$DefaultTableFactory.createTable(MaterializationService.java:374)
> at
> org.apache.calcite.materialize.MaterializationService.defineMaterialization(MaterializationService.java:137)
> at
> org.apache.calcite.materialize.MaterializationService.defineMaterialization(MaterializationService.java:99)
> at
> org.apache.calcite.schema.impl.MaterializedViewTable$MaterializedViewTableMacro.(MaterializedViewTable.java:110)
> at
> org.apache.calcite.schema.impl.MaterializedViewTable$MaterializedViewTableMacro.(MaterializedViewTable.java:100)
> at
> org.apache.calcite.schema.impl.MaterializedViewTable.create(MaterializedViewTable.java:81)
> at org.apache.calcite.model.ModelHandler.visit(ModelHandler.java:364)
> at
> org.apache.calcite.model.JsonMaterialization.accept(JsonMaterialization.java:42)
> at org.apache.calcite.model.JsonSchema.visitChildren(JsonSchema.java:98)
> at
> org.apache.calcite.model.JsonMapSchema.visitChildren(JsonMapSchema.java:48)
> at
> org.apache.calcite.model.ModelHandler.populateSchema(ModelHandler.java:257)
> at org.apache.calcite.model.ModelHandler.visit(ModelHandler.java:273)
> at
> org.apache.calcite.model.JsonCustomSchema.accept(JsonCustomSchema.java:45)
> at
[jira] [Closed] (CALCITE-2036) /docs/powered_by.html has a next of /docs/api.html which does not exist
[ https://issues.apache.org/jira/browse/CALCITE-2036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Roytman closed CALCITE-2036. --- Resolution: Resolved Checked Avatica, too, and it's OK now. Closing. > /docs/powered_by.html has a next of /docs/api.html which does not exist > --- > > Key: CALCITE-2036 > URL: https://issues.apache.org/jira/browse/CALCITE-2036 > Project: Calcite > Issue Type: Bug > Components: site >Affects Versions: 1.14.0 >Reporter: Alexey Roytman >Assignee: Michael Mior >Priority: Minor > > The bottom of this page: https://calcite.apache.org/docs/powered_by.html > has two buttons: previous and next. > The "next" points to https://calcite.apache.org/docs/api.html > which is absent. > The site/_data/docs.yml has "api" item after "powered_by" item. > And site/_includes/section_nav.html makes the "next" link to have ".html" > appended. > Thus "api.html" string is created. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-2036) /docs/powered_by.html has a next of /docs/api.html which does not exist
[ https://issues.apache.org/jira/browse/CALCITE-2036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16251344#comment-16251344 ] Michael Mior commented on CALCITE-2036: --- Sorry, missed that comment. This is fixed for Avatica now as well. > /docs/powered_by.html has a next of /docs/api.html which does not exist > --- > > Key: CALCITE-2036 > URL: https://issues.apache.org/jira/browse/CALCITE-2036 > Project: Calcite > Issue Type: Bug > Components: site >Affects Versions: 1.14.0 >Reporter: Alexey Roytman >Assignee: Michael Mior >Priority: Minor > > The bottom of this page: https://calcite.apache.org/docs/powered_by.html > has two buttons: previous and next. > The "next" points to https://calcite.apache.org/docs/api.html > which is absent. > The site/_data/docs.yml has "api" item after "powered_by" item. > And site/_includes/section_nav.html makes the "next" link to have ".html" > appended. > Thus "api.html" string is created. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Reopened] (CALCITE-2036) /docs/powered_by.html has a next of /docs/api.html which does not exist
[ https://issues.apache.org/jira/browse/CALCITE-2036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Roytman reopened CALCITE-2036: - What shall we say about the same issue on the Avatica site (see my 1st comment)? > /docs/powered_by.html has a next of /docs/api.html which does not exist > --- > > Key: CALCITE-2036 > URL: https://issues.apache.org/jira/browse/CALCITE-2036 > Project: Calcite > Issue Type: Bug > Components: site >Affects Versions: 1.14.0 >Reporter: Alexey Roytman >Assignee: Michael Mior >Priority: Minor > > The bottom of this page: https://calcite.apache.org/docs/powered_by.html > has two buttons: previous and next. > The "next" points to https://calcite.apache.org/docs/api.html > which is absent. > The site/_data/docs.yml has "api" item after "powered_by" item. > And site/_includes/section_nav.html makes the "next" link to have ".html" > appended. > Thus "api.html" string is created. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (CALCITE-2036) /docs/powered_by.html has a next of /docs/api.html which does not exist
[ https://issues.apache.org/jira/browse/CALCITE-2036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Roytman closed CALCITE-2036. --- Checked the site -- works. Closing. > /docs/powered_by.html has a next of /docs/api.html which does not exist > --- > > Key: CALCITE-2036 > URL: https://issues.apache.org/jira/browse/CALCITE-2036 > Project: Calcite > Issue Type: Bug > Components: site >Affects Versions: 1.14.0 >Reporter: Alexey Roytman >Assignee: Michael Mior >Priority: Minor > > The bottom of this page: https://calcite.apache.org/docs/powered_by.html > has two buttons: previous and next. > The "next" points to https://calcite.apache.org/docs/api.html > which is absent. > The site/_data/docs.yml has "api" item after "powered_by" item. > And site/_includes/section_nav.html makes the "next" link to have ".html" > appended. > Thus "api.html" string is created. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-2044) Tweak cost of BindableTableScan to make sure Project is pushed through Aggregate
[ https://issues.apache.org/jira/browse/CALCITE-2044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16251195#comment-16251195 ] Luis Fernando Kauer commented on CALCITE-2044: -- Thanks, Julian. Looks great. I changed typeFactory.builder() because it is deprecated and javadoc recomends using Builder, not because I don't like it. I thought I was updating to the recommended way to do it. Should I continue using typeFactory.builder() for now? > Tweak cost of BindableTableScan to make sure Project is pushed through > Aggregate > > > Key: CALCITE-2044 > URL: https://issues.apache.org/jira/browse/CALCITE-2044 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: Luis Fernando Kauer >Assignee: Julian Hyde >Priority: Minor > > Similar to [CALCITE-1876]. > Projects are not pushed to BindableTableScan when using > ProjectableFilterableTable with aggregate functions. > The reason is that the cost of BindableTableScan does not use projects (and > filters), so the planner chooses a plan with Project node removed by > ProjectRemoveRule. > By tweaking the cost to use the number of used projects solved the problem. > Any suggestion on the cost formula to take both projects and filters into > account? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
