[jira] [Commented] (CALCITE-2043) Use custom RelBuilder implementation in some rules
[ https://issues.apache.org/jira/browse/CALCITE-2043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16251037#comment-16251037 ] Julian Hyde commented on CALCITE-2043: -- I've reviewed https://github.com/apache/calcite/pull/564/commits/16d786cadcad45430a14a231f39852b1d2f5b735; looks good, now testing. > Use custom RelBuilder implementation in some rules > -- > > Key: CALCITE-2043 > URL: https://issues.apache.org/jira/browse/CALCITE-2043 > Project: Calcite > Issue Type: Bug >Reporter: Volodymyr Vysotskyi >Assignee: Julian Hyde > > Some rules do not have constructors with RelBuilderFactory. > List of such rules that are used in Drill: > * AggregateRemoveRule > * ProjectRemoveRule > * SortRemoveRule > * ProjectWindowTransposeRule > * ExpandConversionRule > * ConverterRule > * JoinToMultiJoinRule > * ProjectToWindowRule -- 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=16250752#comment-16250752
]
Julian Hyde commented on CALCITE-2044:
--
Reviewing
https://github.com/apache/calcite/pull/565/commits/ddd2a65f69617f84432d91e72783c6c4b0f3ad25:
* Thanks for modernizing ScannableTableTest - much needed!
* I intend to go a bit further and change {{returns}} to {{returnsUnordered}}
in a few places.
* I don't understand why you changed {{typeFactory.builder()}} in a couple of
places - could I revert? (Yes I know FieldInfoBuilder is not nice but it is
deprecated so it won't be with us forever.)
> 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-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=16250614#comment-16250614 ] Michael Mior commented on CALCITE-2036: --- Done. I was going to avoid it because this resulted in partial changes to files. I ended up just using git-svn to commit only the changed parts so this should be live soon. > /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=16250597#comment-16250597 ] Julian Hyde commented on CALCITE-2036: -- I sometimes deploy the site selectively. For example I recently deployed community.html to add some talks but did not deploy reference.html with features that will only arrive in 1.15. I think that would be appropriate here. > /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=16250571#comment-16250571 ] Michael Mior commented on CALCITE-2036: --- Fixed in [830801b6e|https://github.com/apache/calcite/commit/830801b6e9fabc9203e3b2094b9fd0640a3ab8c6]. Not deploying immediately since it looks like there are other site changes that I'm not sure should be live right now. > /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] [Resolved] (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 ] Michael Mior resolved CALCITE-2036. --- Resolution: Fixed > /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=16250555#comment-16250555 ] Julian Hyde commented on CALCITE-2036: -- I saw your fix [830801b6|http://git-wip-us.apache.org/repos/asf/calcite/commit/830801b6]. Let me know if you'd like me to re-deploy the site. > /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=16250551#comment-16250551 ] Julian Hyde commented on CALCITE-2036: -- Sounds good. Since this is the site, not the product, hacks are fine! > /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=16250546#comment-16250546
]
Michael Mior commented on CALCITE-2036:
---
Good point. It's a bit of a hack, but I could just add a replace that changes
{{/docs/api.html}} to {{/apidocs/}} since this is the only case that happens
(we don't have next/previous links on the API pages). Tested this and it works.
Sound good?
> /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-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=16250528#comment-16250528
]
Julian Hyde commented on CALCITE-2016:
--
One thing you could do is to keep the field name as a character literal, as you
have it, and fix the unparse method. However, that doesn't validate the field
name. So, better, I think, is to change the validation of the DOT operator so
that it doesn't try to validate the field name argument as an identifier.
{{SqlAsOperator.validateCall}} already deals with this problem.
Can you add a test to {{SqlValidatorTest}} to make sure that referring to an
unknown field gives an error?
> 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"
[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=16250516#comment-16250516
]
Shuyi Chen commented on CALCITE-2016:
-
Hi [~julianhyde], you are right, I did try to parse 'myfield' as a
SqlIdentifier. However, I am hitting the problem of subfield validation.
Basically, 'myfield' will be parsed as a standalone SqlIdentifier, and in the
validation process, it will try to fullyQualify the SqlIdentifier, which the
validation scope won't be able to find 'myfield' as it's nested under a top
level field.
The approach I was taking basically treat DOT similar to ITEM. In ITEM, you
don't need to check the second operand as it's a literal. So the current
implementation
will bypass checking if the subfield actually exist in the record.
Also, I think about extend SqlIdentifier(see CompoundIdentifier()) itself to
support both ITEM and DOT. However, in that case, you can't support complex
expression in the ITEM operand, e.g.
`A`.`B`[(1+udf(`C`)].`D`.
What's your recommendation? 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" ...
>
[jira] [Commented] (CALCITE-2048) Create a better documentation for the Planner design
[ https://issues.apache.org/jira/browse/CALCITE-2048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250365#comment-16250365 ] Julian Hyde commented on CALCITE-2048: -- I agree there are are lot of concepts to cover. However if we document the concepts one after the other it would read like a service manual and be so difficult to read that it will not enlighten anyone. I think a better approach is to describe particular use cases as worked examples. Start with a simple use case. Then introduce an example that uses a custom cost model. And so forth. The examples would explain not only how to create a custom cost model but also why you would want to. Documentation for the concepts is probably best left to the javadoc for those classes (which already exists) and to a presentation (which would introduce the concepts, and have a slide for each concept, but not contain full working examples). > Create a better documentation for the Planner design > > > Key: CALCITE-2048 > URL: https://issues.apache.org/jira/browse/CALCITE-2048 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Edmon Begoli >Assignee: Edmon Begoli >Priority: Minor > Original Estimate: 672h > Remaining Estimate: 672h > > Per request of the development community, and the assessment that we need a > tutorial, documentation and example code to work directly with the planner, > because it is a lot harder to work with the planner than with an adapter. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[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=16250348#comment-16250348
]
Julian Hyde commented on CALCITE-2016:
--
[~suez1224], With your parser changes, you have made {{select myrecord .
'myfield' from mytable}} into valid SQL but I think it should not be. Do you
agree?
> 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
>
[jira] [Comment Edited] (CALCITE-1998) Hive - Version specific handling for NULLS FIRST/ NULLS LAST
[ https://issues.apache.org/jira/browse/CALCITE-1998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250347#comment-16250347 ] Julian Hyde edited comment on CALCITE-1998 at 11/13/17 10:12 PM: - I was initially worried that we needed to generate "order by isnull\(x), x" for MySQL, but I tried "order by x is null, x" and it worked fine, so I think we're OK. was (Author: julianhyde): I was initially worried that we needed to generate "order by isnull(x), x" for MySQL, but I tried "order by x is null, x" and it worked fine, so I think we're OK. > Hive - Version specific handling for NULLS FIRST/ NULLS LAST > > > Key: CALCITE-1998 > URL: https://issues.apache.org/jira/browse/CALCITE-1998 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.15.0 >Reporter: Abbas Gadhia >Assignee: Julian Hyde >Priority: Minor > Fix For: 1.15.0 > > > This JIRA is for PR https://github.com/apache/calcite/pull/545 > We are making the HiveSqlDialect version aware for the NULLS FIRST and NULLS > LAST feature. In https://issues.apache.org/jira/browse/HIVE-12994 , the > authors clarified that the default NullCollation for Hive is > "NullDirection.LOW". Currently, the DEFAULT set in Calcite for Hive is > NullCollation.HIGH > In this PR, we are making 2 changes. > # Change the default NullCollation from HIGH to LOW > # Add NullCollation emulation in the HiveSqlDialect when the version of the > dialect is less that 2.1.0 or when the version is blank. > We're also adding a new Dialect "BigQuerySqlDialect" with the "quoteString" > as "`" based on > https://cloud.google.com/bigquery/docs/reference/standard-sql/lexical -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (CALCITE-1998) Hive - Version specific handling for NULLS FIRST/ NULLS LAST
[
https://issues.apache.org/jira/browse/CALCITE-1998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16241626#comment-16241626
]
Julian Hyde edited comment on CALCITE-1998 at 11/13/17 10:11 PM:
-
Hi [~julianhyde], I just noticed that {{MysqlSqlDialect}} still uses "x is
null" instead of isnull\(x). Did you intend to leave it that way or was it an
oversight?
was (Author: nerrve):
Hi [~julianhyde], I just noticed that the MysqlDialect still uses "x is null"
instead of isnull(x). Did you intend to leave it that way or was it an
oversight?
> Hive - Version specific handling for NULLS FIRST/ NULLS LAST
>
>
> Key: CALCITE-1998
> URL: https://issues.apache.org/jira/browse/CALCITE-1998
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.15.0
>Reporter: Abbas Gadhia
>Assignee: Julian Hyde
>Priority: Minor
> Fix For: 1.15.0
>
>
> This JIRA is for PR https://github.com/apache/calcite/pull/545
> We are making the HiveSqlDialect version aware for the NULLS FIRST and NULLS
> LAST feature. In https://issues.apache.org/jira/browse/HIVE-12994 , the
> authors clarified that the default NullCollation for Hive is
> "NullDirection.LOW". Currently, the DEFAULT set in Calcite for Hive is
> NullCollation.HIGH
> In this PR, we are making 2 changes.
> # Change the default NullCollation from HIGH to LOW
> # Add NullCollation emulation in the HiveSqlDialect when the version of the
> dialect is less that 2.1.0 or when the version is blank.
> We're also adding a new Dialect "BigQuerySqlDialect" with the "quoteString"
> as "`" based on
> https://cloud.google.com/bigquery/docs/reference/standard-sql/lexical
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-1998) Hive - Version specific handling for NULLS FIRST/ NULLS LAST
[ https://issues.apache.org/jira/browse/CALCITE-1998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250347#comment-16250347 ] Julian Hyde commented on CALCITE-1998: -- I was initially worried that we needed to generate "order by isnull(x), x" for MySQL, but I tried "order by x is null, x" and it worked fine, so I think we're OK. > Hive - Version specific handling for NULLS FIRST/ NULLS LAST > > > Key: CALCITE-1998 > URL: https://issues.apache.org/jira/browse/CALCITE-1998 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.15.0 >Reporter: Abbas Gadhia >Assignee: Julian Hyde >Priority: Minor > Fix For: 1.15.0 > > > This JIRA is for PR https://github.com/apache/calcite/pull/545 > We are making the HiveSqlDialect version aware for the NULLS FIRST and NULLS > LAST feature. In https://issues.apache.org/jira/browse/HIVE-12994 , the > authors clarified that the default NullCollation for Hive is > "NullDirection.LOW". Currently, the DEFAULT set in Calcite for Hive is > NullCollation.HIGH > In this PR, we are making 2 changes. > # Change the default NullCollation from HIGH to LOW > # Add NullCollation emulation in the HiveSqlDialect when the version of the > dialect is less that 2.1.0 or when the version is blank. > We're also adding a new Dialect "BigQuerySqlDialect" with the "quoteString" > as "`" based on > https://cloud.google.com/bigquery/docs/reference/standard-sql/lexical -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-2048) Create a better documentation for the Planner design
[ https://issues.apache.org/jira/browse/CALCITE-2048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250346#comment-16250346 ] Enrico Olivelli commented on CALCITE-2048: -- Maybe it would be useful a simple guide to plains explanations, like a showcase with a set of queries and for each query: - logical plan (after parse) - final plan (after findBestExp) - explanation of the RelNodes - variants based on : stats, Table implemented marker interfaces, conventions, TraitDefs, other important config (which I have not discovered yet) Javadocs in general seems well written, but a global introduction is the real gap > Create a better documentation for the Planner design > > > Key: CALCITE-2048 > URL: https://issues.apache.org/jira/browse/CALCITE-2048 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Edmon Begoli >Assignee: Edmon Begoli >Priority: Minor > Original Estimate: 672h > Remaining Estimate: 672h > > Per request of the development community, and the assessment that we need a > tutorial, documentation and example code to work directly with the planner, > because it is a lot harder to work with the planner than with an adapter. -- 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=16250344#comment-16250344 ] Julian Hyde commented on CALCITE-2036: -- I'm not an expert in jekyll, but the simplest thing might be to change the code that generates the "next" button. > /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=16250341#comment-16250341
]
Julian Hyde commented on CALCITE-2036:
--
If it's just some one-time changes to pages, that's OK. Or would it be more
than that?
I'm also worried that the redirect may not work well if there are parameters at
the end of the URL. For example, what would the URL
https://calcite.apache.org/apidocs/org/apache/calcite/rel/RelNode.html#getInput-int-
(for the method {{RelNode.getInput(int)}}) be in the new scheme?
> /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] [Comment Edited] (CALCITE-2048) Create a better documentation for the Planner design
[ https://issues.apache.org/jira/browse/CALCITE-2048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250024#comment-16250024 ] Julian Hyde edited comment on CALCITE-2048 at 11/13/17 9:48 PM: I agree with Enrico. The documentation should explain many concepts used in the planner, such as TraitDef, TraitSet, Convention, Program, Enumerable, Bindable, Program, Rules, transformation/conversion of nodes in rules, implementation of nodes, statistics, RelMetadataQuery, costs. There are so many concepts. I think examples or just snippets showing and explaining how they are used would help a lot. We could also have a module with a full planner example with: - configurable schema/catalog via json, so there is no need to use any adapter or create the schema somewhere else; - configurable cost and metadata also via json, so it can be used to test different setups; - show the best plan for each query, which rules where applied and the optimized SQL. This would help test new rules, changes to costs and different queries easily using different setups. Maybe even integrate with Cosette (CALCITE-1977) to validate whether the optimized SQL is really equivalent to the query. was (Author: lfkauer): I agree with Enrico. The documentation should explain many concepts used in the planner, such as TraitDef, TraitSet, Convention, Program, Enumerable, Bindable, Program, Rules, transformation/conversion of nodes in rules, implementation of nodes, statistics, RelMetadataQuery, costs. There are so many concepts. I think examples or just snippets showing and explaining how they are used would help a lot. We could also have a module with a full planner example with: - configurable schema/catalog via json, so there is no need to use any adapter or create the schema somewhere else; - configurable cost and metadata also via json, so it can be used to test different setups; - show the best plan for each query, which rules where applied and the optimized SQL. This would help test new rules, changes to costs and different queries easily using different setups. Maybe even integrate with Cosette (Calcite-1977) to validate whether the optimized SQL is really equivalent to the query. > Create a better documentation for the Planner design > > > Key: CALCITE-2048 > URL: https://issues.apache.org/jira/browse/CALCITE-2048 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Edmon Begoli >Assignee: Edmon Begoli >Priority: Minor > Original Estimate: 672h > Remaining Estimate: 672h > > Per request of the development community, and the assessment that we need a > tutorial, documentation and example code to work directly with the planner, > because it is a lot harder to work with the planner than with an adapter. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (CALCITE-2048) Create a better documentation for the Planner design
[
https://issues.apache.org/jira/browse/CALCITE-2048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16249028#comment-16249028
]
Julian Hyde edited comment on CALCITE-2048 at 11/13/17 9:47 PM:
>From dev mailing list, from [~julianhyde]:
{quote}
1. I would run planner tests (e.g. RelOptRulesTest, PlannerTest,
VolcanoPlannerTest) in a debugger. I would turn on tracing and try to
understand the output.
Frameworks and Planner may be useful classes if you find it difficult to create
the environment needed for a planner.
2. VolcanoPlanner.findBestExp()
3. I don’t know - it’s a complex piece of code
4. no - except for the parser
5. not much
These are very quick answers. Others, please chime in with your answers.
{quote}
was (Author: ebegoli):
>From dev mailing list, from [~julianhyde]:
1. I would run planner tests (e.g. RelOptRulesTest, PlannerTest,
VolcanoPlannerTest) in a debugger. I would turn on tracing and try to
understand the output.
Frameworks and Planner may be useful classes if you find it difficult to create
the environment needed for a planner.
2. VolcanoPlanner.findBestExp()
3. I don’t know - it’s a complex piece of code
4. no - except for the parser
5. not much
These are very quick answers. Others, please chime in with your answers.
> Create a better documentation for the Planner design
>
>
> Key: CALCITE-2048
> URL: https://issues.apache.org/jira/browse/CALCITE-2048
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Edmon Begoli
>Assignee: Edmon Begoli
>Priority: Minor
> Original Estimate: 672h
> Remaining Estimate: 672h
>
> Per request of the development community, and the assessment that we need a
> tutorial, documentation and example code to work directly with the planner,
> because it is a lot harder to work with the planner than with an adapter.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-1048) Make metadata more robust
[ https://issues.apache.org/jira/browse/CALCITE-1048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250297#comment-16250297 ] Julian Hyde commented on CALCITE-1048: -- Basically, yes. I was thinking of doing the same thing in a more abstract way, namely providing a "[fold|https://en.wikipedia.org/wiki/Fold_(higher-order_function)]" function. > Make metadata more robust > - > > Key: CALCITE-1048 > URL: https://issues.apache.org/jira/browse/CALCITE-1048 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Julian Hyde > > Following CALCITE-794, make metadata more robust and performant, so we can > safely derive metadata from a large RelNode graph. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-2048) Create a better documentation for the Planner design
[ https://issues.apache.org/jira/browse/CALCITE-2048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250024#comment-16250024 ] Luis Fernando Kauer commented on CALCITE-2048: -- I agree with Enrico. The documentation should explain many concepts used in the planner, such as TraitDef, TraitSet, Convention, Program, Enumerable, Bindable, Program, Rules, transformation/conversion of nodes in rules, implementation of nodes, statistics, RelMetadataQuery, costs. There are so many concepts. I think examples or just snippets showing and explaining how they are used would help a lot. We could also have a module with a full planner example with: - configurable schema/catalog via json, so there is no need to use any adapter or create the schema somewhere else; - configurable cost and metadata also via json, so it can be used to test different setups; - show the best plan for each query, which rules where applied and the optimized SQL. This would help test new rules, changes to costs and different queries easily using different setups. Maybe even integrate with Cosette (Calcite-1977) to validate whether the optimized SQL is really equivalent to the query. > Create a better documentation for the Planner design > > > Key: CALCITE-2048 > URL: https://issues.apache.org/jira/browse/CALCITE-2048 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Edmon Begoli >Assignee: Edmon Begoli >Priority: Minor > Original Estimate: 672h > Remaining Estimate: 672h > > Per request of the development community, and the assessment that we need a > tutorial, documentation and example code to work directly with the planner, > because it is a lot harder to work with the planner than with an adapter. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-2048) Create a better documentation for the Planner design
[ https://issues.apache.org/jira/browse/CALCITE-2048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16249833#comment-16249833 ] Enrico Olivelli commented on CALCITE-2048: -- I have started using Calcite planner, my first thoughts: - we need a working example, I can provide snippets - a glossary is needed, to undestand the components and the concepts, like Emumerable, TeaitraotitDef, Convention, Program, Table - we need a description of what is a table, and that the interfaces are used as markers to drive the Planner I will continue to comment here to add other ideas > Create a better documentation for the Planner design > > > Key: CALCITE-2048 > URL: https://issues.apache.org/jira/browse/CALCITE-2048 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Edmon Begoli >Assignee: Edmon Begoli >Priority: Minor > Original Estimate: 672h > Remaining Estimate: 672h > > Per request of the development community, and the assessment that we need a > tutorial, documentation and example code to work directly with the planner, > because it is a lot harder to work with the planner than with an adapter. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
