[jira] [Comment Edited] (CALCITE-3349) Add Function DDL into SqlKind DDL enum
[
https://issues.apache.org/jira/browse/CALCITE-3349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16931726#comment-16931726
]
Shuyi Chen edited comment on CALCITE-3349 at 9/17/19 6:22 PM:
--
Hi [~ZhenqiuHuang], I suggest implement SqlExecutableStatement for
Sql\{Create/Drop}Function, and throw an exception to expose the problem
explicitly. And then create a subsequent Jira to implement the execute()
function.
I understand it's not the intention of this PR, but given the reviewer resource
as well as the size of the suggested changes, I think we can combine them in
one PR. What do you think?
was (Author: suez1224):
Hi [~ZhenqiuHuang], I suggest implement SqlExecutableStatement for
Sql\{Create/Drop}Function, and throw an exception to expose the problem
explicitly. And then create a subsequent Jira to implement the execute()
function.
> Add Function DDL into SqlKind DDL enum
> --
>
> Key: CALCITE-3349
> URL: https://issues.apache.org/jira/browse/CALCITE-3349
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Zhenqiu Huang
>Priority: Minor
> Labels: pull-request-available
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Currently, Create Function, Drop Function are not added into SqlKind DDL
> enum.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (CALCITE-3349) Add Function DDL into SqlKind DDL enum
[
https://issues.apache.org/jira/browse/CALCITE-3349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16931726#comment-16931726
]
Shuyi Chen commented on CALCITE-3349:
-
Hi [~ZhenqiuHuang], I suggest implement SqlExecutableStatement for
Sql\{Create/Drop}Function, and throw an exception to expose the problem
explicitly. And then create a subsequent Jira to implement the execute()
function.
> Add Function DDL into SqlKind DDL enum
> --
>
> Key: CALCITE-3349
> URL: https://issues.apache.org/jira/browse/CALCITE-3349
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Zhenqiu Huang
>Priority: Minor
> Labels: pull-request-available
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Currently, Create Function, Drop Function are not added into SqlKind DDL
> enum.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (CALCITE-2542) SqlNode AtomicRowExpression + DOT operation does not work for constructed ROWs
[
https://issues.apache.org/jira/browse/CALCITE-2542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16678780#comment-16678780
]
Shuyi Chen commented on CALCITE-2542:
-
Thanks for the work, Rong! I think you need to also add test in
SqlValidatorTest and SqlToRelConverterTest as well.
[~julianhyde], can you give an example of a function(arg, ...) on the right
side of a dot operator? I think method is not supported for record type, right?
> SqlNode AtomicRowExpression + DOT operation does not work for constructed ROWs
> --
>
> Key: CALCITE-2542
> URL: https://issues.apache.org/jira/browse/CALCITE-2542
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Rong Rong
>Assignee: Julian Hyde
>Priority: Major
>
> It seems like some of the {{AtomicRowExpression}} (such as
> {{NamedFunctionCall}}) or rowSpan with {{}} operator does not allow
> following DOT operators in Parser.jj
> To named a few, the following does not parse correctly.
> {code}
> SELECT ROW(col1, col2, col3).col1 FROM t
> SELECT myFunc(arg1, arg2).col1 FROM t
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2440) SQL with UNNEST fail in volcano planner in some cases
[
https://issues.apache.org/jira/browse/CALCITE-2440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16586993#comment-16586993
]
Shuyi Chen commented on CALCITE-2440:
-
Thanks a lot for the pointer, [~vvysotskyi]. Yes, I found the a rule assuming
Correlate -> Uncollect, but can't match Correlate -> Project -> Uncollect after
the change in CALCITE-2291. Will fix the rule in the target project. Closing
this ticket as invalid.
> SQL with UNNEST fail in volcano planner in some cases
> -
>
> Key: CALCITE-2440
> URL: https://issues.apache.org/jira/browse/CALCITE-2440
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: Shuyi Chen
>Assignee: Julian Hyde
>Priority: Major
>
> After [CALCITE-2291|https://issues.apache.org/jira/browse/CALCITE-2291],
> specifically, [this
> line|https://github.com/apache/calcite/blob/7088dc7261d294b7c6d5c9f4463435e95f0b9c15/core/src/main/java/org/apache/calcite/sql2rel/SqlToRelConverter.java#L1952]
> causes volcano planner to fail to find the best plan for query
> {code:java}
> SELECT a, s FROM T, UNNEST(T.c) as A (s)
> {code}
> . I'll try to write a unittest in Calcite to reproduce. [~cshi] [~vvysotskyi]
> [~HanumathRao], can you provide some context? Thanks a lot.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (CALCITE-2440) SQL with UNNEST fail in volcano planner in some cases
[
https://issues.apache.org/jira/browse/CALCITE-2440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shuyi Chen closed CALCITE-2440.
---
Resolution: Invalid
> SQL with UNNEST fail in volcano planner in some cases
> -
>
> Key: CALCITE-2440
> URL: https://issues.apache.org/jira/browse/CALCITE-2440
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: Shuyi Chen
>Assignee: Julian Hyde
>Priority: Major
>
> After [CALCITE-2291|https://issues.apache.org/jira/browse/CALCITE-2291],
> specifically, [this
> line|https://github.com/apache/calcite/blob/7088dc7261d294b7c6d5c9f4463435e95f0b9c15/core/src/main/java/org/apache/calcite/sql2rel/SqlToRelConverter.java#L1952]
> causes volcano planner to fail to find the best plan for query
> {code:java}
> SELECT a, s FROM T, UNNEST(T.c) as A (s)
> {code}
> . I'll try to write a unittest in Calcite to reproduce. [~cshi] [~vvysotskyi]
> [~HanumathRao], can you provide some context? Thanks a lot.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2440) SQL with UNNEST fail in volcano planner in some cases
[
https://issues.apache.org/jira/browse/CALCITE-2440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16585420#comment-16585420
]
Shuyi Chen commented on CALCITE-2440:
-
[~vvysotskyi], thanks a lot. There are 52 rules together, it's hard to identify
the set. After running the volcanoplanner, the relsubset.best is null and
bestCost is {inf}. Do you have any idea on what might be the cause so I can
narrow down the search space?
> SQL with UNNEST fail in volcano planner in some cases
> -
>
> Key: CALCITE-2440
> URL: https://issues.apache.org/jira/browse/CALCITE-2440
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: Shuyi Chen
>Assignee: Julian Hyde
>Priority: Major
>
> After [CALCITE-2291|https://issues.apache.org/jira/browse/CALCITE-2291],
> specifically, [this
> line|https://github.com/apache/calcite/blob/7088dc7261d294b7c6d5c9f4463435e95f0b9c15/core/src/main/java/org/apache/calcite/sql2rel/SqlToRelConverter.java#L1952]
> causes volcano planner to fail to find the best plan for query
> {code:java}
> SELECT a, s FROM T, UNNEST(T.c) as A (s)
> {code}
> . I'll try to write a unittest in Calcite to reproduce. [~cshi] [~vvysotskyi]
> [~HanumathRao], can you provide some context? Thanks a lot.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2440) SQL with UNNEST fail in volcano planner in some cases
[
https://issues.apache.org/jira/browse/CALCITE-2440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16583181#comment-16583181
]
Shuyi Chen commented on CALCITE-2440:
-
[~vvysotskyi], table "T" does contains column "a". Could you please point me to
the unittest that causes the loss of field aliases?
[~julianhyde], do you have any good suggestion for me to reproduce the issue in
calcite to debug the volcano planner? I hit the issue when I upgrade Apache
Flink to use Calcite 1.17. But Flink have many rules and it's hard to find out
which set of rules cause the issue. Thanks a lot.
> SQL with UNNEST fail in volcano planner in some cases
> -
>
> Key: CALCITE-2440
> URL: https://issues.apache.org/jira/browse/CALCITE-2440
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: Shuyi Chen
>Assignee: Julian Hyde
>Priority: Major
>
> After [CALCITE-2291|https://issues.apache.org/jira/browse/CALCITE-2291],
> specifically, [this
> line|https://github.com/apache/calcite/blob/7088dc7261d294b7c6d5c9f4463435e95f0b9c15/core/src/main/java/org/apache/calcite/sql2rel/SqlToRelConverter.java#L1952]
> causes volcano planner to fail to find the best plan for query
> {code:java}
> SELECT a, s FROM T, UNNEST(T.c) as A (s)
> {code}
> . I'll try to write a unittest in Calcite to reproduce. [~cshi] [~vvysotskyi]
> [~HanumathRao], can you provide some context? Thanks a lot.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (CALCITE-2466) RexSimplify incorrectly simplify conjunction statement with null literal
[
https://issues.apache.org/jira/browse/CALCITE-2466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shuyi Chen closed CALCITE-2466.
---
Resolution: Invalid
> RexSimplify incorrectly simplify conjunction statement with null literal
>
>
> Key: CALCITE-2466
> URL: https://issues.apache.org/jira/browse/CALCITE-2466
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Shuyi Chen
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.18.0
>
>
> This can be reproduced using the following test:
> {code:java}
> @Test public void testFilterReduction() throws Exception {
> HepProgramBuilder programBuilder = HepProgram.builder();
> programBuilder.addRuleInstance(ReduceExpressionsRule.FILTER_INSTANCE);
> HepPlanner planner = new HepPlanner(programBuilder.build());
> final String sql = "select deptno from dept_nested where NAME <> '' AND
> employees <> null";
> planner.setRoot(tester.convertSqlToRel(sql).rel);
> RelNode bestRel = planner.findBestExp();
> assertEquals(
> "LogicalProject(DEPTNO=[$0])\n" +
> " LogicalFilter(condition=[AND(<>($1, ''), <>($3, null))])\n" +
> "LogicalTableScan(table=[[CATALOG, SALES, DEPT_NESTED]])\n",
> RelOptUtil.toString(bestRel));
> }
> {code}
> In this test,
> {code:java}
> NAME <> '' AND employees <> null
> {code} is always evaluated to false incorrectly, so the optimized plan is
> {code:java}
> LogicalProject(DEPTNO=[$0])
> LogicalValues(tuples=[[]])
> {code}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2466) RexSimplify incorrectly simplify conjunction statement with null literal
[
https://issues.apache.org/jira/browse/CALCITE-2466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16582683#comment-16582683
]
Shuyi Chen commented on CALCITE-2466:
-
[~julianhyde], [~vladimirsitnikov], thanks for the info. This is actually valid
SQL. I'll close the JIRA.
> RexSimplify incorrectly simplify conjunction statement with null literal
>
>
> Key: CALCITE-2466
> URL: https://issues.apache.org/jira/browse/CALCITE-2466
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Shuyi Chen
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.18.0
>
>
> This can be reproduced using the following test:
> {code:java}
> @Test public void testFilterReduction() throws Exception {
> HepProgramBuilder programBuilder = HepProgram.builder();
> programBuilder.addRuleInstance(ReduceExpressionsRule.FILTER_INSTANCE);
> HepPlanner planner = new HepPlanner(programBuilder.build());
> final String sql = "select deptno from dept_nested where NAME <> '' AND
> employees <> null";
> planner.setRoot(tester.convertSqlToRel(sql).rel);
> RelNode bestRel = planner.findBestExp();
> assertEquals(
> "LogicalProject(DEPTNO=[$0])\n" +
> " LogicalFilter(condition=[AND(<>($1, ''), <>($3, null))])\n" +
> "LogicalTableScan(table=[[CATALOG, SALES, DEPT_NESTED]])\n",
> RelOptUtil.toString(bestRel));
> }
> {code}
> In this test,
> {code:java}
> NAME <> '' AND employees <> null
> {code} is always evaluated to false incorrectly, so the optimized plan is
> {code:java}
> LogicalProject(DEPTNO=[$0])
> LogicalValues(tuples=[[]])
> {code}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2466) RexSimplify incorrectly simplify conjunction statement with null literal
[
https://issues.apache.org/jira/browse/CALCITE-2466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16580456#comment-16580456
]
Shuyi Chen commented on CALCITE-2466:
-
i agree, I am thinking of adding or extending some logic in
SqlBinaryOperator.validateCall() to reject <>, = and other range binary
operators with null value. What do you think, [~julianhyde]?
> RexSimplify incorrectly simplify conjunction statement with null literal
>
>
> Key: CALCITE-2466
> URL: https://issues.apache.org/jira/browse/CALCITE-2466
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Shuyi Chen
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.18.0
>
>
> This can be reproduced using the following test:
> {code:java}
> @Test public void testFilterReduction() throws Exception {
> HepProgramBuilder programBuilder = HepProgram.builder();
> programBuilder.addRuleInstance(ReduceExpressionsRule.FILTER_INSTANCE);
> HepPlanner planner = new HepPlanner(programBuilder.build());
> final String sql = "select deptno from dept_nested where NAME <> '' AND
> employees <> null";
> planner.setRoot(tester.convertSqlToRel(sql).rel);
> RelNode bestRel = planner.findBestExp();
> assertEquals(
> "LogicalProject(DEPTNO=[$0])\n" +
> " LogicalFilter(condition=[AND(<>($1, ''), <>($3, null))])\n" +
> "LogicalTableScan(table=[[CATALOG, SALES, DEPT_NESTED]])\n",
> RelOptUtil.toString(bestRel));
> }
> {code}
> In this test,
> {code:java}
> NAME <> '' AND employees <> null
> {code} is always evaluated to false incorrectly, so the optimized plan is
> {code:java}
> LogicalProject(DEPTNO=[$0])
> LogicalValues(tuples=[[]])
> {code}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2466) RexSimplify incorrectly simplify conjunction statement with null literal
[
https://issues.apache.org/jira/browse/CALCITE-2466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16580246#comment-16580246
]
Shuyi Chen commented on CALCITE-2466:
-
so does it mean we only support is NULL or IS NOT NULL for null comparison? I
thought *=* and *<>* has the same meaning of *IS NULL* or *IS NOT NULL*.I think
we can either allow *=* and *<>* with null, or in validation phase, throw an
exception for this kind of statement. What do you think, [~julianhyde]?
> RexSimplify incorrectly simplify conjunction statement with null literal
>
>
> Key: CALCITE-2466
> URL: https://issues.apache.org/jira/browse/CALCITE-2466
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Shuyi Chen
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.18.0
>
>
> This can be reproduced using the following test:
> {code:java}
> @Test public void testFilterReduction() throws Exception {
> HepProgramBuilder programBuilder = HepProgram.builder();
> programBuilder.addRuleInstance(ReduceExpressionsRule.FILTER_INSTANCE);
> HepPlanner planner = new HepPlanner(programBuilder.build());
> final String sql = "select deptno from dept_nested where NAME <> '' AND
> employees <> null";
> planner.setRoot(tester.convertSqlToRel(sql).rel);
> RelNode bestRel = planner.findBestExp();
> assertEquals(
> "LogicalProject(DEPTNO=[$0])\n" +
> " LogicalFilter(condition=[AND(<>($1, ''), <>($3, null))])\n" +
> "LogicalTableScan(table=[[CATALOG, SALES, DEPT_NESTED]])\n",
> RelOptUtil.toString(bestRel));
> }
> {code}
> In this test,
> {code:java}
> NAME <> '' AND employees <> null
> {code} is always evaluated to false incorrectly, so the optimized plan is
> {code:java}
> LogicalProject(DEPTNO=[$0])
> LogicalValues(tuples=[[]])
> {code}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2466) RexSimplify incorrectly simplify conjunction statement with null literal
[
https://issues.apache.org/jira/browse/CALCITE-2466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16580184#comment-16580184
]
Shuyi Chen commented on CALCITE-2466:
-
Also, I've created a PR [here|https://github.com/apache/calcite/pull/792], you
can take a quick look on the test cases I added and see if it makes sense.
> RexSimplify incorrectly simplify conjunction statement with null literal
>
>
> Key: CALCITE-2466
> URL: https://issues.apache.org/jira/browse/CALCITE-2466
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Shuyi Chen
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.18.0
>
>
> This can be reproduced using the following test:
> {code:java}
> @Test public void testFilterReduction() throws Exception {
> HepProgramBuilder programBuilder = HepProgram.builder();
> programBuilder.addRuleInstance(ReduceExpressionsRule.FILTER_INSTANCE);
> HepPlanner planner = new HepPlanner(programBuilder.build());
> final String sql = "select deptno from dept_nested where NAME <> '' AND
> employees <> null";
> planner.setRoot(tester.convertSqlToRel(sql).rel);
> RelNode bestRel = planner.findBestExp();
> assertEquals(
> "LogicalProject(DEPTNO=[$0])\n" +
> " LogicalFilter(condition=[AND(<>($1, ''), <>($3, null))])\n" +
> "LogicalTableScan(table=[[CATALOG, SALES, DEPT_NESTED]])\n",
> RelOptUtil.toString(bestRel));
> }
> {code}
> In this test,
> {code:java}
> NAME <> '' AND employees <> null
> {code} is always evaluated to false incorrectly, so the optimized plan is
> {code:java}
> LogicalProject(DEPTNO=[$0])
> LogicalValues(tuples=[[]])
> {code}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2466) RexSimplify incorrectly simplify conjunction statement with null literal
[
https://issues.apache.org/jira/browse/CALCITE-2466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16580180#comment-16580180
]
Shuyi Chen commented on CALCITE-2466:
-
Thanks a lot, [~julianhyde], in
{code:java}
select deptno from dept_nested where NAME <> '' AND employees <> null
{code},
if NAME is empty string and employees is a valid array (non null), then it
should not return empty row, right?
> RexSimplify incorrectly simplify conjunction statement with null literal
>
>
> Key: CALCITE-2466
> URL: https://issues.apache.org/jira/browse/CALCITE-2466
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Shuyi Chen
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.18.0
>
>
> This can be reproduced using the following test:
> {code:java}
> @Test public void testFilterReduction() throws Exception {
> HepProgramBuilder programBuilder = HepProgram.builder();
> programBuilder.addRuleInstance(ReduceExpressionsRule.FILTER_INSTANCE);
> HepPlanner planner = new HepPlanner(programBuilder.build());
> final String sql = "select deptno from dept_nested where NAME <> '' AND
> employees <> null";
> planner.setRoot(tester.convertSqlToRel(sql).rel);
> RelNode bestRel = planner.findBestExp();
> assertEquals(
> "LogicalProject(DEPTNO=[$0])\n" +
> " LogicalFilter(condition=[AND(<>($1, ''), <>($3, null))])\n" +
> "LogicalTableScan(table=[[CATALOG, SALES, DEPT_NESTED]])\n",
> RelOptUtil.toString(bestRel));
> }
> {code}
> In this test,
> {code:java}
> NAME <> '' AND employees <> null
> {code} is always evaluated to false incorrectly, so the optimized plan is
> {code:java}
> LogicalProject(DEPTNO=[$0])
> LogicalValues(tuples=[[]])
> {code}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CALCITE-2466) RexSimplify incorrectly simplify conjunction statement with null literal
Shuyi Chen created CALCITE-2466:
---
Summary: RexSimplify incorrectly simplify conjunction statement
with null literal
Key: CALCITE-2466
URL: https://issues.apache.org/jira/browse/CALCITE-2466
Project: Calcite
Issue Type: Bug
Components: core
Reporter: Shuyi Chen
Assignee: Julian Hyde
Fix For: 1.18.0
This can be reproduced using the following test:
{code:java}
@Test public void testFilterReduction() throws Exception {
HepProgramBuilder programBuilder = HepProgram.builder();
programBuilder.addRuleInstance(ReduceExpressionsRule.FILTER_INSTANCE);
HepPlanner planner = new HepPlanner(programBuilder.build());
final String sql = "select deptno from dept_nested where NAME <> '' AND
employees <> null";
planner.setRoot(tester.convertSqlToRel(sql).rel);
RelNode bestRel = planner.findBestExp();
assertEquals(
"LogicalProject(DEPTNO=[$0])\n" +
" LogicalFilter(condition=[AND(<>($1, ''), <>($3, null))])\n" +
"LogicalTableScan(table=[[CATALOG, SALES, DEPT_NESTED]])\n",
RelOptUtil.toString(bestRel));
}
{code}
In this test,
{code:java}
NAME <> '' AND employees <> null
{code} is always evaluated to false incorrectly, so the optimized plan is
{code:java}
LogicalProject(DEPTNO=[$0])
LogicalValues(tuples=[[]])
{code}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (CALCITE-2353) Allow user to override SqlSetOption in alterStatementParserMethods
[ https://issues.apache.org/jira/browse/CALCITE-2353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shuyi Chen closed CALCITE-2353. --- Resolution: Fixed > Allow user to override SqlSetOption in alterStatementParserMethods > -- > > Key: CALCITE-2353 > URL: https://issues.apache.org/jira/browse/CALCITE-2353 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: Andrew Pilloud >Assignee: Shuyi Chen >Priority: Major > Fix For: 1.17.0 > > > If alterStatementParserMethods are added before SqlSetOption then the user > can replace SqlSetOption. This change matches how statementParserMethods are > added at the top level. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2353) Allow user to override SqlSetOption in alterStatementParserMethods
[ https://issues.apache.org/jira/browse/CALCITE-2353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16505563#comment-16505563 ] Shuyi Chen commented on CALCITE-2353: - Fixed in [aaf4471|https://github.com/apache/calcite/commit/aaf44711ae2b01ab97be93dafd86dd97b75e5101]. > Allow user to override SqlSetOption in alterStatementParserMethods > -- > > Key: CALCITE-2353 > URL: https://issues.apache.org/jira/browse/CALCITE-2353 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: Andrew Pilloud >Assignee: Shuyi Chen >Priority: Major > Fix For: 1.17.0 > > > If alterStatementParserMethods are added before SqlSetOption then the user > can replace SqlSetOption. This change matches how statementParserMethods are > added at the top level. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2353) Allow user to override SqlSetOption in alterStatementParserMethods
[ https://issues.apache.org/jira/browse/CALCITE-2353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16504306#comment-16504306 ] Shuyi Chen commented on CALCITE-2353: - Hi [~julianhyde], assigning this ticket to me for review. Let me know if you have any comment otherwise. > Allow user to override SqlSetOption in alterStatementParserMethods > -- > > Key: CALCITE-2353 > URL: https://issues.apache.org/jira/browse/CALCITE-2353 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: Andrew Pilloud >Assignee: Shuyi Chen >Priority: Major > > If alterStatementParserMethods are added before SqlSetOption then the user > can replace SqlSetOption. This change matches how statementParserMethods are > added at the top level. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (CALCITE-2353) Allow user to override SqlSetOption in alterStatementParserMethods
[ https://issues.apache.org/jira/browse/CALCITE-2353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shuyi Chen reassigned CALCITE-2353: --- Assignee: Shuyi Chen (was: Julian Hyde) > Allow user to override SqlSetOption in alterStatementParserMethods > -- > > Key: CALCITE-2353 > URL: https://issues.apache.org/jira/browse/CALCITE-2353 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: Andrew Pilloud >Assignee: Shuyi Chen >Priority: Major > > If alterStatementParserMethods are added before SqlSetOption then the user > can replace SqlSetOption. This change matches how statementParserMethods are > added at the top level. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2353) Allow user to override SqlSetOption in alterStatementParserMethods
[ https://issues.apache.org/jira/browse/CALCITE-2353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16502690#comment-16502690 ] Shuyi Chen commented on CALCITE-2353: - By swapping the order, the parser will match the user DDL rule first, so you can implement your own SET operation, is that what you intend to do? I am not an expert in the parser logic, but it sounds fine to me. > Allow user to override SqlSetOption in alterStatementParserMethods > -- > > Key: CALCITE-2353 > URL: https://issues.apache.org/jira/browse/CALCITE-2353 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: Andrew Pilloud >Assignee: Julian Hyde >Priority: Major > > If alterStatementParserMethods are added before SqlSetOption then the user > can replace SqlSetOption. This change matches how statementParserMethods are > added at the top level. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2209) Support loading JSON model file through URL
[ https://issues.apache.org/jira/browse/CALCITE-2209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16495823#comment-16495823 ] Shuyi Chen commented on CALCITE-2209: - Thanks a lot, Rong. Could we add a dummy protocol with a testing URLStreamHandlerFactory to verify that it works? > Support loading JSON model file through URL > --- > > Key: CALCITE-2209 > URL: https://issues.apache.org/jira/browse/CALCITE-2209 > Project: Calcite > Issue Type: New Feature > Components: core >Reporter: Shuyi Chen >Assignee: Shuyi Chen >Priority: Major > > Currently, Calcite only support loading JSON model file through inline or > local file. The Jira attemps to extend it to support loading JSON model file > through URL, so users can implement their own URLStreamHandlerFactory to read > the JSON model file from e.g., HDFS or etc. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2266) Implement SQL 2016 JSON functions
[ https://issues.apache.org/jira/browse/CALCITE-2266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16494764#comment-16494764 ] Shuyi Chen commented on CALCITE-2266: - Hi [~michaelmior], when do you think this will be ready? The Flink community is also interested in integrating the SQL 2016 JSON functions. > Implement SQL 2016 JSON functions > - > > Key: CALCITE-2266 > URL: https://issues.apache.org/jira/browse/CALCITE-2266 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Michael Mior >Assignee: Michael Mior >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2209) Support loading JSON model file through URL
[ https://issues.apache.org/jira/browse/CALCITE-2209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16484393#comment-16484393 ] Shuyi Chen commented on CALCITE-2209: - [~walterddr], thanks for the work. Can we dig deeper into how Jackson ObjectMapper can be extended and handle other schemas like hdfs:// or custom URL schema? > Support loading JSON model file through URL > --- > > Key: CALCITE-2209 > URL: https://issues.apache.org/jira/browse/CALCITE-2209 > Project: Calcite > Issue Type: New Feature > Components: core >Reporter: Shuyi Chen >Assignee: Shuyi Chen >Priority: Major > > Currently, Calcite only support loading JSON model file through inline or > local file. The Jira attemps to extend it to support loading JSON model file > through URL, so users can implement their own URLStreamHandlerFactory to read > the JSON model file from e.g., HDFS or etc. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2276) Calcite unable to parse ROW value constructor in certain scenario
[
https://issues.apache.org/jira/browse/CALCITE-2276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16451864#comment-16451864
]
Shuyi Chen commented on CALCITE-2276:
-
awesome, thanks for contributing, [~danny0405], Let us know if you need help.
> Calcite unable to parse ROW value constructor in certain scenario
> -
>
> Key: CALCITE-2276
> URL: https://issues.apache.org/jira/browse/CALCITE-2276
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Shuyi Chen
>Assignee: Julian Hyde
>Priority: Major
>
> h2. Original dev mailing list question:
> Now for our production, we can parse a query successfully like this :
> {code}
> -- correlated IN subquery
> -- TC 01.01
> SELECT t1a,
>t1b,
>t1h
> FROM t1
> WHERE ( t1a, t1h ) NOT IN (SELECT t2a,
>t2h
> FROM t2
> WHERE t2a = t1a
> ORDER BY t2a)
> AND t1a = 'val1a'
> {code}
> but if we add in `Row`:
> {code}
> -- correlated IN subquery
> -- TC 01.01
> SELECT t1a,
>t1b,
>t1h
> FROM t1
> WHERE ROW( t1a, t1h ) NOT IN (SELECT t2a,
>t2h
> FROM t2
> WHERE t2a = t1a
> ORDER BY t2a)
> AND t1a = 'val1a'
> {code}
> it will throw exception:
> {noformat}
> Caused by: org.apache.calcite.sql.parser.SqlParseException: ROW expression
> encountered in illegal context
> at
> org.apache.calcite.sql.parser.impl.SqlParserImpl.convertException(SqlParserImpl.java:351)
> at
> org.apache.calcite.sql.parser.impl.SqlParserImpl.normalizeException(SqlParserImpl.java:133)
> at org.apache.calcite.sql.parser.SqlParser.parseQuery(SqlParser.java:138)
> at org.apache.calcite.sql.parser.SqlParser.parseStmt(SqlParser.java:163)
> at
> org.apache.flink.table.calcite.FlinkPlannerImpl.parse(FlinkPlannerImpl.scala:81)
> ... 8 more
> {noformat}
> For the success query, if we exec parsed AST tree rootNode.toString(), it
> will return a query like:
> {code}
> SELECT `t1a`,
>`t1b`,
>`t1h`
> FROM `t1`
> WHERE ROW(`t1a`, `t1h`) NOT IN (SELECT `t2a`, `t2h`
> FROM `t2`
> WHERE `t2a` = `t1a`
> ORDER BY `t2a`)
> AND `t1a` = 'val1a'
> {code}
> This is inconsistent by Calcite itself semantic.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2276) Calcite unable to parse ROW value constructor in certain scenario
[
https://issues.apache.org/jira/browse/CALCITE-2276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16451672#comment-16451672
]
Shuyi Chen commented on CALCITE-2276:
-
I recalled in standard SQL, ROW(...) and (...) is equivalent and ROW is
optional.
[~michaelmior], [~julianhyde] do you want take on this? Otherwise, I can take a
look at it while working on
[CALCITE-2251|https://issues.apache.org/jira/browse/CALCITE-2251] as this will
need some fix in the parser.
> Calcite unable to parse ROW value constructor in certain scenario
> -
>
> Key: CALCITE-2276
> URL: https://issues.apache.org/jira/browse/CALCITE-2276
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Shuyi Chen
>Assignee: Julian Hyde
>Priority: Major
>
> h2. Original dev mailing list question:
> Now for our production, we can parse a query successfully like this :
> {code}
> -- correlated IN subquery
> -- TC 01.01
> SELECT t1a,
>t1b,
>t1h
> FROM t1
> WHERE ( t1a, t1h ) NOT IN (SELECT t2a,
>t2h
> FROM t2
> WHERE t2a = t1a
> ORDER BY t2a)
> AND t1a = 'val1a'
> {code}
> but if we add in `Row`:
> {code}
> -- correlated IN subquery
> -- TC 01.01
> SELECT t1a,
>t1b,
>t1h
> FROM t1
> WHERE ROW( t1a, t1h ) NOT IN (SELECT t2a,
>t2h
> FROM t2
> WHERE t2a = t1a
> ORDER BY t2a)
> AND t1a = 'val1a'
> {code}
> it will throw exception:
> {noformat}
> Caused by: org.apache.calcite.sql.parser.SqlParseException: ROW expression
> encountered in illegal context
> at
> org.apache.calcite.sql.parser.impl.SqlParserImpl.convertException(SqlParserImpl.java:351)
> at
> org.apache.calcite.sql.parser.impl.SqlParserImpl.normalizeException(SqlParserImpl.java:133)
> at org.apache.calcite.sql.parser.SqlParser.parseQuery(SqlParser.java:138)
> at org.apache.calcite.sql.parser.SqlParser.parseStmt(SqlParser.java:163)
> at
> org.apache.flink.table.calcite.FlinkPlannerImpl.parse(FlinkPlannerImpl.scala:81)
> ... 8 more
> {noformat}
> For the success query, if we exec parsed AST tree rootNode.toString(), it
> will return a query like:
> {code}
> SELECT `t1a`,
>`t1b`,
>`t1h`
> FROM `t1`
> WHERE ROW(`t1a`, `t1h`) NOT IN (SELECT `t2a`, `t2h`
> FROM `t2`
> WHERE `t2a` = `t1a`
> ORDER BY `t2a`)
> AND `t1a` = 'val1a'
> {code}
> This is inconsistent by Calcite itself semantic.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CALCITE-2276) Calcite unable to parse ROW value constructor in certain scenario
Shuyi Chen created CALCITE-2276: --- Summary: Calcite unable to parse ROW value constructor in certain scenario Key: CALCITE-2276 URL: https://issues.apache.org/jira/browse/CALCITE-2276 Project: Calcite Issue Type: Bug Components: core Reporter: Shuyi Chen Assignee: Julian Hyde h2. Original dev mailing list question: Now for our production, we can parse a query successfully like this : -- correlated IN subquery -- TC 01.01 SELECT t1a, t1b, t1h FROM t1 WHERE ( t1a, t1h ) NOT IN (SELECT t2a, t2h FROM t2 WHERE t2a = t1a ORDER BY t2a) AND t1a = 'val1a' but if we add in `Row`: -- correlated IN subquery -- TC 01.01 SELECT t1a, t1b, t1h FROM t1 WHERE ROW( t1a, t1h ) NOT IN (SELECT t2a, t2h FROM t2 WHERE t2a = t1a ORDER BY t2a) AND t1a = 'val1a' it will throw exception: Caused by: org.apache.calcite.sql.parser.SqlParseException: ROW expression encountered in illegal context at org.apache.calcite.sql.parser.impl.SqlParserImpl.convertException(SqlParserImpl.java:351) at org.apache.calcite.sql.parser.impl.SqlParserImpl.normalizeException(SqlParserImpl.java:133) at org.apache.calcite.sql.parser.SqlParser.parseQuery(SqlParser.java:138) at org.apache.calcite.sql.parser.SqlParser.parseStmt(SqlParser.java:163) at org.apache.flink.table.calcite.FlinkPlannerImpl.parse(FlinkPlannerImpl.scala:81) ... 8 more For the success query, if we exec parsed AST tree rootNode.toString(), it will return a query like: SELECT `t1a`, `t1b`, `t1h` FROM `t1` WHERE ROW(`t1a`, `t1h`) NOT IN (SELECT `t2a`, `t2h` FROM `t2` WHERE `t2a` = `t1a` ORDER BY `t2a`) AND `t1a` = 'val1a' This is inconsistent by Calcite itself semantic. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (CALCITE-2209) Support loading JSON model file through URL
[ https://issues.apache.org/jira/browse/CALCITE-2209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shuyi Chen reassigned CALCITE-2209: --- Assignee: Julian Hyde (was: Shuyi Chen) > Support loading JSON model file through URL > --- > > Key: CALCITE-2209 > URL: https://issues.apache.org/jira/browse/CALCITE-2209 > Project: Calcite > Issue Type: New Feature > Components: core >Reporter: Shuyi Chen >Assignee: Julian Hyde >Priority: Major > > Currently, Calcite only support loading JSON model file through inline or > local file. The Jira attemps to extend it to support loading JSON model file > through URL, so users can implement their own URLStreamHandlerFactory to read > the JSON model file from e.g., HDFS or etc. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (CALCITE-2209) Support loading JSON model file through URL
[ https://issues.apache.org/jira/browse/CALCITE-2209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shuyi Chen reassigned CALCITE-2209: --- Assignee: Shuyi Chen (was: Julian Hyde) > Support loading JSON model file through URL > --- > > Key: CALCITE-2209 > URL: https://issues.apache.org/jira/browse/CALCITE-2209 > Project: Calcite > Issue Type: New Feature > Components: core >Reporter: Shuyi Chen >Assignee: Shuyi Chen >Priority: Major > > Currently, Calcite only support loading JSON model file through inline or > local file. The Jira attemps to extend it to support loading JSON model file > through URL, so users can implement their own URLStreamHandlerFactory to read > the JSON model file from e.g., HDFS or etc. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-2252) Add supported SQL Dialects in Calcite website
Shuyi Chen created CALCITE-2252: --- Summary: Add supported SQL Dialects in Calcite website Key: CALCITE-2252 URL: https://issues.apache.org/jira/browse/CALCITE-2252 Project: Calcite Issue Type: Improvement Reporter: Shuyi Chen Assignee: Shuyi Chen We can add the SQL dialect section in https://calcite.apache.org/docs/adapter.html. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-2251) Support AS STRUCT syntax to create named STRUCT in SQL similar to Google BigQuery
Shuyi Chen created CALCITE-2251:
---
Summary: Support AS STRUCT syntax to create named STRUCT in SQL
similar to Google BigQuery
Key: CALCITE-2251
URL: https://issues.apache.org/jira/browse/CALCITE-2251
Project: Calcite
Issue Type: New Feature
Components: core
Reporter: Shuyi Chen
Assignee: Shuyi Chen
See [Google BigQuery
grammar|https://cloud.google.com/bigquery/docs/reference/standard-sql/query-syntax].
We want to support something like the following:
{code:java}
SELECT STRUCT(a as first_name, b as last_name, STRUCT(c as zip code, d as
street, e as state) as address) as record FROM example_table
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (CALCITE-2216) Improve extensibility of AggregateReduceFunctionsRule
[
https://issues.apache.org/jira/browse/CALCITE-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shuyi Chen reassigned CALCITE-2216:
---
Assignee: Shuyi Chen (was: Julian Hyde)
> Improve extensibility of AggregateReduceFunctionsRule
> -
>
> Key: CALCITE-2216
> URL: https://issues.apache.org/jira/browse/CALCITE-2216
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.15.0
>Reporter: Fabian Hueske
>Assignee: Shuyi Chen
>Priority: Minor
> Fix For: 1.17.0
>
>
> I'm proposing to improve the extensibility of
> {{AggregateReduceFunctionsRule}}. The purpose of the rule is to decompose
> complex aggregation functions like {{VAR_POP}} and {{STDDEV_SAMP}} into
> {{COUNT}} and {{SUM}} functions and compute the original functions in a
> subsequent Calc operator.
> Right now, the rule class provides a {{protected}} method that can be
> overridden to create an {{Aggregate}} with the updated aggregate calls.
> We are using the rule in Flink and have a special {{Aggregate}} Rel for
> group-windowed aggregations ({{GROUP BY TUMBLE/HOP/SESSION}}). Our
> implementation requires to forward some additional fields from the
> {{Aggregate}} for window properties like {{TUMBLE_START}} or {{HOP_END}}. In
> the current form, we cannot extend the rule, because these fields are striped
> off by the {{Calc}} node that is automatically added by the rule.
> I'm proposing to also move the code to create the {{Calc}} into a
> {{protected}} method just like the code to create the new {{Aggregate}}.
> I know, this is a fairly Flink-specific issue, but the code changes are
> minimal (no change in functionality) and it would help us, because we would
> not need to copy the rule and maintain it in Flink.
> I'll open a PR for this. Looking forward to your comments.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (CALCITE-2216) Improve extensibility of AggregateReduceFunctionsRule
[
https://issues.apache.org/jira/browse/CALCITE-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shuyi Chen resolved CALCITE-2216.
-
Resolution: Fixed
Fix Version/s: 1.17.0
> Improve extensibility of AggregateReduceFunctionsRule
> -
>
> Key: CALCITE-2216
> URL: https://issues.apache.org/jira/browse/CALCITE-2216
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.15.0
>Reporter: Fabian Hueske
>Assignee: Julian Hyde
>Priority: Minor
> Fix For: 1.17.0
>
>
> I'm proposing to improve the extensibility of
> {{AggregateReduceFunctionsRule}}. The purpose of the rule is to decompose
> complex aggregation functions like {{VAR_POP}} and {{STDDEV_SAMP}} into
> {{COUNT}} and {{SUM}} functions and compute the original functions in a
> subsequent Calc operator.
> Right now, the rule class provides a {{protected}} method that can be
> overridden to create an {{Aggregate}} with the updated aggregate calls.
> We are using the rule in Flink and have a special {{Aggregate}} Rel for
> group-windowed aggregations ({{GROUP BY TUMBLE/HOP/SESSION}}). Our
> implementation requires to forward some additional fields from the
> {{Aggregate}} for window properties like {{TUMBLE_START}} or {{HOP_END}}. In
> the current form, we cannot extend the rule, because these fields are striped
> off by the {{Calc}} node that is automatically added by the rule.
> I'm proposing to also move the code to create the {{Calc}} into a
> {{protected}} method just like the code to create the new {{Aggregate}}.
> I know, this is a fairly Flink-specific issue, but the code changes are
> minimal (no change in functionality) and it would help us, because we would
> not need to copy the rule and maintain it in Flink.
> I'll open a PR for this. Looking forward to your comments.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2216) Improve extensibility of AggregateReduceFunctionsRule
[
https://issues.apache.org/jira/browse/CALCITE-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16431016#comment-16431016
]
Shuyi Chen commented on CALCITE-2216:
-
Closed with Thanks a lot for the PR, [~fhueske]!
> Improve extensibility of AggregateReduceFunctionsRule
> -
>
> Key: CALCITE-2216
> URL: https://issues.apache.org/jira/browse/CALCITE-2216
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.15.0
>Reporter: Fabian Hueske
>Assignee: Julian Hyde
>Priority: Minor
>
> I'm proposing to improve the extensibility of
> {{AggregateReduceFunctionsRule}}. The purpose of the rule is to decompose
> complex aggregation functions like {{VAR_POP}} and {{STDDEV_SAMP}} into
> {{COUNT}} and {{SUM}} functions and compute the original functions in a
> subsequent Calc operator.
> Right now, the rule class provides a {{protected}} method that can be
> overridden to create an {{Aggregate}} with the updated aggregate calls.
> We are using the rule in Flink and have a special {{Aggregate}} Rel for
> group-windowed aggregations ({{GROUP BY TUMBLE/HOP/SESSION}}). Our
> implementation requires to forward some additional fields from the
> {{Aggregate}} for window properties like {{TUMBLE_START}} or {{HOP_END}}. In
> the current form, we cannot extend the rule, because these fields are striped
> off by the {{Calc}} node that is automatically added by the rule.
> I'm proposing to also move the code to create the {{Calc}} into a
> {{protected}} method just like the code to create the new {{Aggregate}}.
> I know, this is a fairly Flink-specific issue, but the code changes are
> minimal (no change in functionality) and it would help us, because we would
> not need to copy the rule and maintain it in Flink.
> I'll open a PR for this. Looking forward to your comments.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2216) Improve extensibility of AggregateReduceFunctionsRule
[
https://issues.apache.org/jira/browse/CALCITE-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16431019#comment-16431019
]
Shuyi Chen commented on CALCITE-2216:
-
Merged with
[06080ff|https://git1-us-west.apache.org/repos/asf?p=calcite.git;a=commit;h=06080ff].
Thanks a lot for the PR, [~fhueske].
> Improve extensibility of AggregateReduceFunctionsRule
> -
>
> Key: CALCITE-2216
> URL: https://issues.apache.org/jira/browse/CALCITE-2216
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.15.0
>Reporter: Fabian Hueske
>Assignee: Julian Hyde
>Priority: Minor
>
> I'm proposing to improve the extensibility of
> {{AggregateReduceFunctionsRule}}. The purpose of the rule is to decompose
> complex aggregation functions like {{VAR_POP}} and {{STDDEV_SAMP}} into
> {{COUNT}} and {{SUM}} functions and compute the original functions in a
> subsequent Calc operator.
> Right now, the rule class provides a {{protected}} method that can be
> overridden to create an {{Aggregate}} with the updated aggregate calls.
> We are using the rule in Flink and have a special {{Aggregate}} Rel for
> group-windowed aggregations ({{GROUP BY TUMBLE/HOP/SESSION}}). Our
> implementation requires to forward some additional fields from the
> {{Aggregate}} for window properties like {{TUMBLE_START}} or {{HOP_END}}. In
> the current form, we cannot extend the rule, because these fields are striped
> off by the {{Calc}} node that is automatically added by the rule.
> I'm proposing to also move the code to create the {{Calc}} into a
> {{protected}} method just like the code to create the new {{Aggregate}}.
> I know, this is a fairly Flink-specific issue, but the code changes are
> minimal (no change in functionality) and it would help us, because we would
> not need to copy the rule and maintain it in Flink.
> I'll open a PR for this. Looking forward to your comments.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (CALCITE-2216) Improve extensibility of AggregateReduceFunctionsRule
[
https://issues.apache.org/jira/browse/CALCITE-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shuyi Chen updated CALCITE-2216:
Comment: was deleted
(was: Closed with Thanks a lot for the PR, [~fhueske]!)
> Improve extensibility of AggregateReduceFunctionsRule
> -
>
> Key: CALCITE-2216
> URL: https://issues.apache.org/jira/browse/CALCITE-2216
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.15.0
>Reporter: Fabian Hueske
>Assignee: Julian Hyde
>Priority: Minor
>
> I'm proposing to improve the extensibility of
> {{AggregateReduceFunctionsRule}}. The purpose of the rule is to decompose
> complex aggregation functions like {{VAR_POP}} and {{STDDEV_SAMP}} into
> {{COUNT}} and {{SUM}} functions and compute the original functions in a
> subsequent Calc operator.
> Right now, the rule class provides a {{protected}} method that can be
> overridden to create an {{Aggregate}} with the updated aggregate calls.
> We are using the rule in Flink and have a special {{Aggregate}} Rel for
> group-windowed aggregations ({{GROUP BY TUMBLE/HOP/SESSION}}). Our
> implementation requires to forward some additional fields from the
> {{Aggregate}} for window properties like {{TUMBLE_START}} or {{HOP_END}}. In
> the current form, we cannot extend the rule, because these fields are striped
> off by the {{Calc}} node that is automatically added by the rule.
> I'm proposing to also move the code to create the {{Calc}} into a
> {{protected}} method just like the code to create the new {{Aggregate}}.
> I know, this is a fairly Flink-specific issue, but the code changes are
> minimal (no change in functionality) and it would help us, because we would
> not need to copy the rule and maintain it in Flink.
> I'll open a PR for this. Looking forward to your comments.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2224) WITHIN GROUP clause for aggregate functions
[
https://issues.apache.org/jira/browse/CALCITE-2224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16416503#comment-16416503
]
Shuyi Chen commented on CALCITE-2224:
-
Are you planning to work on this, [~julianhyde]? I can help otherwise.
> WITHIN GROUP clause for aggregate functions
> ---
>
> Key: CALCITE-2224
> URL: https://issues.apache.org/jira/browse/CALCITE-2224
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
>
> The {{WITHIN GROUP}} clause lets aggregate functions operate on a sorted list
> of rows, rather than the usual unsorted collection. Order only matters for a
> few aggregate functions, but we should allow it for all.
> Other analytic functions where {{WITHIN GROUP}} would have an effect:
> {{RANK}}, {{PERCENT_RANK}}, {{FIRST_VALUE}}, {{LAST_VALUE}},
> {{PERCENTILE_CONT}}, {{PERCENTILE_DISC}}.
> {{LISTAGG(value [, separator])}} is an [Oracle
> function|https://docs.oracle.com/cloud/latest/db112/SQLRF/functions089.htm#SQLRF30030]
> that concatenates strings. E.g.
> {code:java}
> SELECT LISTAGG(last_name, '; ')
> WITHIN GROUP (ORDER BY hire_date, last_name)
> FROM Emp
> GROUP BY deptno{code}
> {{STRING_AGG(value [, separator])}} is a [Microsoft SQL Server function|]
> that does something similar.
> {{GROUP_CONCAT(value [, separator] [ORDER BY expr [, expr]...)}} is the
> [MySQL|https://dev.mysql.com/doc/refman/5.7/en/group-by-functions.html#function_group-concat]
> equivalent to {{LISTAGG}}. Note the optional {{ORDER BY}} clause within the
> parentheses.
> {{COLLECT(value)}} is a SQL standard aggregate function that creates
> multisets. Oracle added a non-standard {{ORDER BY}} clause within the
> parentheses.
> In my opinion, {{WITHIN GROUP}} should always be optional. {{LISTAGG}}
> without {{WITHIN GROUP}} would produce non-deterministic output (which is
> OK); other aggregate functions such as {{MIN}} and {{SUM}} would just ignore
> {{WITHIN GROUP}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2220) SqlToRelConverter generates incorrect ordinal while flattening a record-valued field
[
https://issues.apache.org/jira/browse/CALCITE-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16415124#comment-16415124
]
Shuyi Chen commented on CALCITE-2220:
-
[~julianhyde] , thanks a lot for reviewing PR. The tests for jdk8 pass. Could
you please help merge it?
Also, could you please help take another look at
[CALCITE-2045|https://issues.apache.org/jira/browse/CALCITE-2045]? Thanks a lot.
> SqlToRelConverter generates incorrect ordinal while flattening a
> record-valued field
>
>
> Key: CALCITE-2220
> URL: https://issues.apache.org/jira/browse/CALCITE-2220
> Project: Calcite
> Issue Type: Task
> Components: core
>Reporter: Shuyi Chen
>Assignee: Shuyi Chen
>Priority: Major
>
> SqlToRelConverter generates wrong ordinal when flattening multiple input
> records during converting to RelNode. Issue can be reproduced as follows:
> {code}
> MockTable deptNestedTable =
> MockTable.create(this, salesSchema, "DEPT_NESTED", false, 4);
> deptNestedTable.addColumn("DEPTNO", f.intType, true);
> deptNestedTable.addColumn("NAME", f.varchar10Type);
> deptNestedTable.addColumn("SKILLRECORD", f.skillRecordType);
> deptNestedTable.addColumn("EMPLOYEES", f.empListType);
> registerTable(deptNestedTable);
> {code}
> Run the following test:
> {code}@Test public void testArrayOfRecord() {
> sql("select employees[1] from dept_nested").ok();
> }{code}
> The following error gets thrown when run:
> {noformat}
> java.lang.AssertionError: type mismatch:
> ref:
> RecordType(INTEGER NOT NULL EMPNO, VARCHAR(10) CHARACTER SET "ISO-8859-1"
> COLLATE "ISO-8859-1$en_US$primary" NOT NULL ENAME, RecordType(VARCHAR(10)
> CHARACTER SET "ISO-8859-1" COLLATE "ISO-8859-1$en_US$primary" NOT NULL TYPE,
> VARCHAR(20) CHARACTER SET "ISO-8859-1" COLLATE "ISO-8859-1$en_US$primary" NOT
> NULL DESC) NOT NULL ARRAY NOT NULL SKILLS) NOT NULL ARRAY NOT NULL
> input:
> VARCHAR(20) CHARACTER SET "ISO-8859-1" COLLATE "ISO-8859-1$en_US$primary" NOT
> NULL
> at org.apache.calcite.util.Litmus$1.fail(Litmus.java:31)
> at org.apache.calcite.plan.RelOptUtil.eq(RelOptUtil.java:1838)
> at org.apache.calcite.rex.RexChecker.visitInputRef(RexChecker.java:125)
> at org.apache.calcite.rex.RexChecker.visitInputRef(RexChecker.java:57)
> at org.apache.calcite.rex.RexInputRef.accept(RexInputRef.java:112)
> at org.apache.calcite.rex.RexChecker.visitCall(RexChecker.java:140)
> at org.apache.calcite.rex.RexChecker.visitCall(RexChecker.java:57)
> at org.apache.calcite.rex.RexCall.accept(RexCall.java:107)
> at
> org.apache.calcite.rex.RexVisitorImpl.visitFieldAccess(RexVisitorImpl.java:98)
> at
> org.apache.calcite.rex.RexChecker.visitFieldAccess(RexChecker.java:149)
> at
> org.apache.calcite.rex.RexChecker.visitFieldAccess(RexChecker.java:57)
> at org.apache.calcite.rex.RexFieldAccess.accept(RexFieldAccess.java:81)
> at org.apache.calcite.rel.core.Project.isValid(Project.java:187)
> at org.apache.calcite.rel.core.Project.(Project.java:84)
> at
> org.apache.calcite.rel.logical.LogicalProject.(LogicalProject.java:65)
> at
> org.apache.calcite.rel.logical.LogicalProject.create(LogicalProject.java:120)
> at
> org.apache.calcite.rel.logical.LogicalProject.create(LogicalProject.java:103)
> at
> org.apache.calcite.rel.core.RelFactories$ProjectFactoryImpl.createProject(RelFactories.java:127)
> at org.apache.calcite.tools.RelBuilder.project(RelBuilder.java:1064)
> at
> org.apache.calcite.plan.RelOptUtil.createProject(RelOptUtil.java:2956)
> at
> org.apache.calcite.plan.RelOptUtil.createProject(RelOptUtil.java:2873)
> at
> org.apache.calcite.sql2rel.RelStructuredTypeFlattener.rewriteRel(RelStructuredTypeFlattener.java:477)
> 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.apache.calcite.util.ReflectUtil.invokeVisitorInternal(ReflectUtil.java:257)
> at
> org.apache.calcite.util.ReflectUtil.invokeVisitor(ReflectUtil.java:214)
> at
> org.apache.calcite.util.ReflectUtil$1.invokeVisitor(ReflectUtil.java:464)
> at
> org.apache.calcite.sql2rel.RelStructuredTypeFlattener$RewriteRelVisitor.visit(RelStructuredTypeFlattener.java:721)
> at
> org.apache.calcite.sql2rel.RelStructuredTypeFlattener.rewrite(RelStructuredTypeFlattener.java:177)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.flattenTypes(SqlToRelConverter.java:462)
> at
>
[jira] [Updated] (CALCITE-2221) RelRoot.project does not take into account flattened record type
[
https://issues.apache.org/jira/browse/CALCITE-2221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shuyi Chen updated CALCITE-2221:
Description:
To reproduce, simply run:
@Test public void testFlattenRecords() {
sql("select employees[1] from dept_nested").ok();
}
It will yield:
LogicalProject(EXPR$0=[$0])
LogicalProject(EXPR$0$0=[ITEM($2, 1).EMPNO], EXPR$0$1=[ITEM($2, 1).ENAME],
EXPR$0$2=[ITEM($2, 1).DETAIL])
LogicalTableScan(table=[[CATALOG, SALES, DEPT_NESTED]])
was:
To reproduce, simply run:
@Test public void testFlattenRecords() {
sql("select employees[1] from dept_nested").ok();
}
It will yield:
LogicalProject(EXPR$0=[$0])
LogicalProject(EXPR$0$0=[ITEM($6, 1).EMPNO], EXPR$0$1=[ITEM($6, 1).ENAME],
EXPR$0$2=[ITEM($6, 1).DETAIL])
LogicalProject(DEPTNO=[$0], NAME=[$1], TYPE=[$2.TYPE], DESC=[$2.DESC],
A=[$2.OTHERS.A], B=[$2.OTHERS.B], EMPLOYEES=[$3])
LogicalTableScan(table=[[CATALOG, SALES, DEPT_NESTED]])
> RelRoot.project does not take into account flattened record type
>
>
> Key: CALCITE-2221
> URL: https://issues.apache.org/jira/browse/CALCITE-2221
> Project: Calcite
> Issue Type: Task
> Components: core
>Reporter: Shuyi Chen
>Assignee: Julian Hyde
>Priority: Major
>
> To reproduce, simply run:
> @Test public void testFlattenRecords() {
> sql("select employees[1] from dept_nested").ok();
> }
> It will yield:
> LogicalProject(EXPR$0=[$0])
> LogicalProject(EXPR$0$0=[ITEM($2, 1).EMPNO], EXPR$0$1=[ITEM($2, 1).ENAME],
> EXPR$0$2=[ITEM($2, 1).DETAIL])
> LogicalTableScan(table=[[CATALOG, SALES, DEPT_NESTED]])
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CALCITE-2221) RelRoot.project does not take into account flattened record type
Shuyi Chen created CALCITE-2221:
---
Summary: RelRoot.project does not take into account flattened
record type
Key: CALCITE-2221
URL: https://issues.apache.org/jira/browse/CALCITE-2221
Project: Calcite
Issue Type: Task
Components: core
Reporter: Shuyi Chen
Assignee: Julian Hyde
To reproduce, simply run:
@Test public void testFlattenRecords() {
sql("select employees[1] from dept_nested").ok();
}
It will yield:
LogicalProject(EXPR$0=[$0])
LogicalProject(EXPR$0$0=[ITEM($6, 1).EMPNO], EXPR$0$1=[ITEM($6, 1).ENAME],
EXPR$0$2=[ITEM($6, 1).DETAIL])
LogicalProject(DEPTNO=[$0], NAME=[$1], TYPE=[$2.TYPE], DESC=[$2.DESC],
A=[$2.OTHERS.A], B=[$2.OTHERS.B], EMPLOYEES=[$3])
LogicalTableScan(table=[[CATALOG, SALES, DEPT_NESTED]])
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2220) Wrong ordinal when flattening multiple input records during converting to REL
[
https://issues.apache.org/jira/browse/CALCITE-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16409204#comment-16409204
]
Shuyi Chen commented on CALCITE-2220:
-
[~julianhyde] , can you help take a look at this JIRA and PR?
> Wrong ordinal when flattening multiple input records during converting to REL
> -
>
> Key: CALCITE-2220
> URL: https://issues.apache.org/jira/browse/CALCITE-2220
> Project: Calcite
> Issue Type: Task
> Components: core
>Reporter: Shuyi Chen
>Assignee: Shuyi Chen
>Priority: Major
>
> *Issue can be reproduced as follows*:
> MockTable deptNestedTable =
> MockTable.create(this, salesSchema, "DEPT_NESTED", false, 4);
> deptNestedTable.addColumn("DEPTNO", f.intType, true);
> deptNestedTable.addColumn("NAME", f.varchar10Type);
> deptNestedTable.addColumn("SKILLRECORD", f.skillRecordType);
> deptNestedTable.addColumn("EMPLOYEES", f.empListType);
> registerTable(deptNestedTable);
> Run the following test:
> @Test public void testArrayOfRecord() {
> sql("select employees[1] from dept_nested").ok();
> }
> The following error gets thrown when run:
> java.lang.AssertionError: type mismatch:
> ref:
> RecordType(INTEGER NOT NULL EMPNO, VARCHAR(10) CHARACTER SET "ISO-8859-1"
> COLLATE "ISO-8859-1$en_US$primary" NOT NULL ENAME, RecordType(VARCHAR(10)
> CHARACTER SET "ISO-8859-1" COLLATE "ISO-8859-1$en_US$primary" NOT NULL TYPE,
> VARCHAR(20) CHARACTER SET "ISO-8859-1" COLLATE "ISO-8859-1$en_US$primary" NOT
> NULL DESC) NOT NULL ARRAY NOT NULL SKILLS) NOT NULL ARRAY NOT NULL
> input:
> VARCHAR(20) CHARACTER SET "ISO-8859-1" COLLATE "ISO-8859-1$en_US$primary" NOT
> NULL
> at org.apache.calcite.util.Litmus$1.fail(Litmus.java:31)
> at org.apache.calcite.plan.RelOptUtil.eq(RelOptUtil.java:1838)
> at org.apache.calcite.rex.RexChecker.visitInputRef(RexChecker.java:125)
> at org.apache.calcite.rex.RexChecker.visitInputRef(RexChecker.java:57)
> at org.apache.calcite.rex.RexInputRef.accept(RexInputRef.java:112)
> at org.apache.calcite.rex.RexChecker.visitCall(RexChecker.java:140)
> at org.apache.calcite.rex.RexChecker.visitCall(RexChecker.java:57)
> at org.apache.calcite.rex.RexCall.accept(RexCall.java:107)
> at
> org.apache.calcite.rex.RexVisitorImpl.visitFieldAccess(RexVisitorImpl.java:98)
> at
> org.apache.calcite.rex.RexChecker.visitFieldAccess(RexChecker.java:149)
> at
> org.apache.calcite.rex.RexChecker.visitFieldAccess(RexChecker.java:57)
> at org.apache.calcite.rex.RexFieldAccess.accept(RexFieldAccess.java:81)
> at org.apache.calcite.rel.core.Project.isValid(Project.java:187)
> at org.apache.calcite.rel.core.Project.(Project.java:84)
> at
> org.apache.calcite.rel.logical.LogicalProject.(LogicalProject.java:65)
> at
> org.apache.calcite.rel.logical.LogicalProject.create(LogicalProject.java:120)
> at
> org.apache.calcite.rel.logical.LogicalProject.create(LogicalProject.java:103)
> at
> org.apache.calcite.rel.core.RelFactories$ProjectFactoryImpl.createProject(RelFactories.java:127)
> at org.apache.calcite.tools.RelBuilder.project(RelBuilder.java:1064)
> at
> org.apache.calcite.plan.RelOptUtil.createProject(RelOptUtil.java:2956)
> at
> org.apache.calcite.plan.RelOptUtil.createProject(RelOptUtil.java:2873)
> at
> org.apache.calcite.sql2rel.RelStructuredTypeFlattener.rewriteRel(RelStructuredTypeFlattener.java:477)
> 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.apache.calcite.util.ReflectUtil.invokeVisitorInternal(ReflectUtil.java:257)
> at
> org.apache.calcite.util.ReflectUtil.invokeVisitor(ReflectUtil.java:214)
> at
> org.apache.calcite.util.ReflectUtil$1.invokeVisitor(ReflectUtil.java:464)
> at
> org.apache.calcite.sql2rel.RelStructuredTypeFlattener$RewriteRelVisitor.visit(RelStructuredTypeFlattener.java:721)
> at
> org.apache.calcite.sql2rel.RelStructuredTypeFlattener.rewrite(RelStructuredTypeFlattener.java:177)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.flattenTypes(SqlToRelConverter.java:462)
> at
> org.apache.calcite.test.SqlToRelTestBase$TesterImpl.convertSqlToRel(SqlToRelTestBase.java:585)
> at
> org.apache.calcite.test.SqlToRelTestBase$TesterImpl.assertConvertsTo(SqlToRelTestBase.java:690)
> at
> org.apache.calcite.test.SqlToRelConverterTest$Sql.convertsTo(SqlToRelConverterTest.java:2784)
> at
>
[jira] [Created] (CALCITE-2220) Wrong ordinal when flattening multiple input records during converting to REL
Shuyi Chen created CALCITE-2220:
---
Summary: Wrong ordinal when flattening multiple input records
during converting to REL
Key: CALCITE-2220
URL: https://issues.apache.org/jira/browse/CALCITE-2220
Project: Calcite
Issue Type: Task
Components: core
Reporter: Shuyi Chen
Assignee: Shuyi Chen
*Issue can be reproduced as follows*:
MockTable deptNestedTable =
MockTable.create(this, salesSchema, "DEPT_NESTED", false, 4);
deptNestedTable.addColumn("DEPTNO", f.intType, true);
deptNestedTable.addColumn("NAME", f.varchar10Type);
deptNestedTable.addColumn("SKILLRECORD", f.skillRecordType);
deptNestedTable.addColumn("EMPLOYEES", f.empListType);
registerTable(deptNestedTable);
Run the following test:
@Test public void testArrayOfRecord() {
sql("select employees[1] from dept_nested").ok();
}
The following error gets thrown when run:
java.lang.AssertionError: type mismatch:
ref:
RecordType(INTEGER NOT NULL EMPNO, VARCHAR(10) CHARACTER SET "ISO-8859-1"
COLLATE "ISO-8859-1$en_US$primary" NOT NULL ENAME, RecordType(VARCHAR(10)
CHARACTER SET "ISO-8859-1" COLLATE "ISO-8859-1$en_US$primary" NOT NULL TYPE,
VARCHAR(20) CHARACTER SET "ISO-8859-1" COLLATE "ISO-8859-1$en_US$primary" NOT
NULL DESC) NOT NULL ARRAY NOT NULL SKILLS) NOT NULL ARRAY NOT NULL
input:
VARCHAR(20) CHARACTER SET "ISO-8859-1" COLLATE "ISO-8859-1$en_US$primary" NOT
NULL
at org.apache.calcite.util.Litmus$1.fail(Litmus.java:31)
at org.apache.calcite.plan.RelOptUtil.eq(RelOptUtil.java:1838)
at org.apache.calcite.rex.RexChecker.visitInputRef(RexChecker.java:125)
at org.apache.calcite.rex.RexChecker.visitInputRef(RexChecker.java:57)
at org.apache.calcite.rex.RexInputRef.accept(RexInputRef.java:112)
at org.apache.calcite.rex.RexChecker.visitCall(RexChecker.java:140)
at org.apache.calcite.rex.RexChecker.visitCall(RexChecker.java:57)
at org.apache.calcite.rex.RexCall.accept(RexCall.java:107)
at
org.apache.calcite.rex.RexVisitorImpl.visitFieldAccess(RexVisitorImpl.java:98)
at
org.apache.calcite.rex.RexChecker.visitFieldAccess(RexChecker.java:149)
at
org.apache.calcite.rex.RexChecker.visitFieldAccess(RexChecker.java:57)
at org.apache.calcite.rex.RexFieldAccess.accept(RexFieldAccess.java:81)
at org.apache.calcite.rel.core.Project.isValid(Project.java:187)
at org.apache.calcite.rel.core.Project.(Project.java:84)
at
org.apache.calcite.rel.logical.LogicalProject.(LogicalProject.java:65)
at
org.apache.calcite.rel.logical.LogicalProject.create(LogicalProject.java:120)
at
org.apache.calcite.rel.logical.LogicalProject.create(LogicalProject.java:103)
at
org.apache.calcite.rel.core.RelFactories$ProjectFactoryImpl.createProject(RelFactories.java:127)
at org.apache.calcite.tools.RelBuilder.project(RelBuilder.java:1064)
at
org.apache.calcite.plan.RelOptUtil.createProject(RelOptUtil.java:2956)
at
org.apache.calcite.plan.RelOptUtil.createProject(RelOptUtil.java:2873)
at
org.apache.calcite.sql2rel.RelStructuredTypeFlattener.rewriteRel(RelStructuredTypeFlattener.java:477)
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.apache.calcite.util.ReflectUtil.invokeVisitorInternal(ReflectUtil.java:257)
at
org.apache.calcite.util.ReflectUtil.invokeVisitor(ReflectUtil.java:214)
at
org.apache.calcite.util.ReflectUtil$1.invokeVisitor(ReflectUtil.java:464)
at
org.apache.calcite.sql2rel.RelStructuredTypeFlattener$RewriteRelVisitor.visit(RelStructuredTypeFlattener.java:721)
at
org.apache.calcite.sql2rel.RelStructuredTypeFlattener.rewrite(RelStructuredTypeFlattener.java:177)
at
org.apache.calcite.sql2rel.SqlToRelConverter.flattenTypes(SqlToRelConverter.java:462)
at
org.apache.calcite.test.SqlToRelTestBase$TesterImpl.convertSqlToRel(SqlToRelTestBase.java:585)
at
org.apache.calcite.test.SqlToRelTestBase$TesterImpl.assertConvertsTo(SqlToRelTestBase.java:690)
at
org.apache.calcite.test.SqlToRelConverterTest$Sql.convertsTo(SqlToRelConverterTest.java:2784)
at
org.apache.calcite.test.SqlToRelConverterTest$Sql.ok(SqlToRelConverterTest.java:2776)
at
org.apache.calcite.test.SqlToRelConverterTest.testArrayOfRecord(SqlToRelConverterTest.java:1059)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[jira] [Commented] (CALCITE-2211) Type of BigInteger should be BIGINT
[ https://issues.apache.org/jira/browse/CALCITE-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16402649#comment-16402649 ] Shuyi Chen commented on CALCITE-2211: - Hi [~eysegal], please free feel to send a PR to add the mapping. > Type of BigInteger should be BIGINT > --- > > Key: CALCITE-2211 > URL: https://issues.apache.org/jira/browse/CALCITE-2211 > Project: Calcite > Issue Type: Bug >Affects Versions: 1.15.0 >Reporter: Eyal Segal >Assignee: Julian Hyde >Priority: Major > > Vertica DB returns BigInteger values as BigInteger. It seems that > JavaToSqlTypeConversionRules doesn't support mapping between BigInteger to > BIGINT. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2217) Upgrade Calcite dependency to 1.17
[ https://issues.apache.org/jira/browse/CALCITE-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16402626#comment-16402626 ] Shuyi Chen commented on CALCITE-2217: - wrong project, mistake. > Upgrade Calcite dependency to 1.17 > -- > > Key: CALCITE-2217 > URL: https://issues.apache.org/jira/browse/CALCITE-2217 > Project: Calcite > Issue Type: Task >Reporter: Shuyi Chen >Assignee: Shuyi Chen >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (CALCITE-2217) Upgrade Calcite dependency to 1.17
[ https://issues.apache.org/jira/browse/CALCITE-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shuyi Chen closed CALCITE-2217. --- Resolution: Invalid > Upgrade Calcite dependency to 1.17 > -- > > Key: CALCITE-2217 > URL: https://issues.apache.org/jira/browse/CALCITE-2217 > Project: Calcite > Issue Type: Task >Reporter: Shuyi Chen >Assignee: Shuyi Chen >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-2217) Upgrade Calcite dependency to 1.17
Shuyi Chen created CALCITE-2217: --- Summary: Upgrade Calcite dependency to 1.17 Key: CALCITE-2217 URL: https://issues.apache.org/jira/browse/CALCITE-2217 Project: Calcite Issue Type: Task Reporter: Shuyi Chen Assignee: Shuyi Chen -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2214) Support CREATE FUNCTION DDL
[ https://issues.apache.org/jira/browse/CALCITE-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shuyi Chen updated CALCITE-2214: Description: We want to add function DDL support like this in [Vertica|https://my.vertica.com/docs/7.2.x/HTML/index.htm#Authoring/SQLReferenceManual/Statements/CREATEFUNCTIONUDF.htm]. Component/s: core > Support CREATE FUNCTION DDL > --- > > Key: CALCITE-2214 > URL: https://issues.apache.org/jira/browse/CALCITE-2214 > Project: Calcite > Issue Type: New Feature > Components: core >Reporter: Shuyi Chen >Assignee: Shuyi Chen >Priority: Major > > We want to add function DDL support like this in > [Vertica|https://my.vertica.com/docs/7.2.x/HTML/index.htm#Authoring/SQLReferenceManual/Statements/CREATEFUNCTIONUDF.htm]. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2046) Support "CREATE LIBRARY" DDL
[
https://issues.apache.org/jira/browse/CALCITE-2046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shuyi Chen updated CALCITE-2046:
Summary: Support "CREATE LIBRARY" DDL (was: Support "CREATE FUNCTION" DDL)
> Support "CREATE LIBRARY" DDL
>
>
> Key: CALCITE-2046
> URL: https://issues.apache.org/jira/browse/CALCITE-2046
> Project: Calcite
> Issue Type: New Feature
>Reporter: Shuyi Chen
>Assignee: Shuyi Chen
>Priority: Major
>
> We want to add DDL support for creating external function like Apache Drill
> ([https://drill.apache.org/docs/create-function-using-jar/]).
> {code:java}
> CREATE FUNCTION USING JAR '.jar';
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CALCITE-2214) Support CREATE FUNCTION DDL
Shuyi Chen created CALCITE-2214: --- Summary: Support CREATE FUNCTION DDL Key: CALCITE-2214 URL: https://issues.apache.org/jira/browse/CALCITE-2214 Project: Calcite Issue Type: New Feature Reporter: Shuyi Chen Assignee: Shuyi Chen -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2046) Support "CREATE FUNCTION" DDL
[
https://issues.apache.org/jira/browse/CALCITE-2046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16399432#comment-16399432
]
Shuyi Chen commented on CALCITE-2046:
-
I think we need another Jira [CREATE
FUNCTION|https://my.vertica.com/docs/7.2.x/HTML/index.htm#Authoring/SQLReferenceManual/Statements/CREATEFUNCTIONUDF.htm]
support.
Also, to load external libraries for code generation when compiling, do you
have any suggestions? I look through the documentation and code, the only
solution I can find is to use the ICookable.setParentClassLoader to replace the
classloader with another one that has the external libraries loaded. I'll
appreciate your insight.
> Support "CREATE FUNCTION" DDL
> -
>
> Key: CALCITE-2046
> URL: https://issues.apache.org/jira/browse/CALCITE-2046
> Project: Calcite
> Issue Type: New Feature
>Reporter: Shuyi Chen
>Assignee: Shuyi Chen
>Priority: Major
>
> We want to add DDL support for creating external function like Apache Drill
> ([https://drill.apache.org/docs/create-function-using-jar/]).
> {code:java}
> CREATE FUNCTION USING JAR '.jar';
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2045) Support "CREATE TYPE" DDL
[ https://issues.apache.org/jira/browse/CALCITE-2045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16399352#comment-16399352 ] Shuyi Chen edited comment on CALCITE-2045 at 3/14/18 8:29 PM: -- Hi [~julianhyde], that sounds good to me. Can you take another look at the PR at your convenience? thanks. was (Author: suez1224): [~julianhyde], sounds good to me. Can you take another look at the PR at your convenience? thanks. > Support "CREATE TYPE" DDL > - > > Key: CALCITE-2045 > URL: https://issues.apache.org/jira/browse/CALCITE-2045 > Project: Calcite > Issue Type: New Feature > Components: core >Reporter: Shuyi Chen >Assignee: Shuyi Chen >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2045) Support "CREATE TYPE" DDL
[ https://issues.apache.org/jira/browse/CALCITE-2045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16399352#comment-16399352 ] Shuyi Chen commented on CALCITE-2045: - [~julianhyde], sounds good to me. Can you take another look at the PR at your convenience? thanks. > Support "CREATE TYPE" DDL > - > > Key: CALCITE-2045 > URL: https://issues.apache.org/jira/browse/CALCITE-2045 > Project: Calcite > Issue Type: New Feature > Components: core >Reporter: Shuyi Chen >Assignee: Shuyi Chen >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2211) Type of BigInteger should be BIGINT
[ https://issues.apache.org/jira/browse/CALCITE-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397750#comment-16397750 ] Shuyi Chen edited comment on CALCITE-2211 at 3/14/18 1:40 AM: -- Good point. java.math.BigInteger has unlimited precision, I dont think there is a sql type equivalent to it. The close I think is decimal. In JavaToSqlTypeConversionRules, we are mapping BigDecimal(unlimited precision) to Sql.Decimal already, so I think we can convert BigInteger to Sql.Decimal as well. Transact-SQL do conversion of integer to Decimal if it's outside the integer range. ([https://docs.microsoft.com/en-us/sql/t-sql/data-types/int-bigint-smallint-and-tinyint-transact-sql#converting-integer-data]. What do you think? was (Author: suez1224): Good point. java.math.BigInteger has unlimited precision, I dont think there is a sql type equivalent to it. The close I think is decimal. In JavaToSqlTypeConversionRules, we are mapping BigDecimal(unlimited precision) to Sql.Decimal already, so I think we can convert BigInteger to Sql.Decimal as well. Transact-SQL do conversion of integer to Decimal if it's outside the integer range. ([https://docs.microsoft.com/en-us/sql/t-sql/data-types/int-bigint-smallint-and-tinyint-transact-sql#converting-integer-data] > Type of BigInteger should be BIGINT > --- > > Key: CALCITE-2211 > URL: https://issues.apache.org/jira/browse/CALCITE-2211 > Project: Calcite > Issue Type: Bug >Affects Versions: 1.15.0 >Reporter: Eyal Segal >Assignee: Julian Hyde >Priority: Major > > Vertica DB returns BigInteger values as BigInteger. It seems that > JavaToSqlTypeConversionRules doesn't support mapping between BigInteger to > BIGINT. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2211) Type of BigInteger should be BIGINT
[ https://issues.apache.org/jira/browse/CALCITE-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397750#comment-16397750 ] Shuyi Chen edited comment on CALCITE-2211 at 3/14/18 1:39 AM: -- Good point. java.math.BigInteger has unlimited precision, I dont think there is a sql type equivalent to it. The close I think is decimal. In JavaToSqlTypeConversionRules, we are mapping BigDecimal(unlimited precision) to Sql.Decimal already, so I think we can convert BigInteger to Sql.Decimal as well. Transact-SQL do conversion of integer to Decimal if it's outside the integer range. ([https://docs.microsoft.com/en-us/sql/t-sql/data-types/int-bigint-smallint-and-tinyint-transact-sql#converting-integer-data] was (Author: suez1224): Good point. java.math.BigInteger has unlimited decision, I dont think there is a sql type equivalent to it. The close I think is decimal. In JavaToSqlTypeConversionRules, we are mapping BigDecimal(unlimited precision) to Sql.Decimal already, so I think we can convert BigInteger to Sql.Decimal as well. Transact-SQL do conversion of integer to Decimal if it's outside the integer range. (https://docs.microsoft.com/en-us/sql/t-sql/data-types/int-bigint-smallint-and-tinyint-transact-sql#converting-integer-data > Type of BigInteger should be BIGINT > --- > > Key: CALCITE-2211 > URL: https://issues.apache.org/jira/browse/CALCITE-2211 > Project: Calcite > Issue Type: Bug >Affects Versions: 1.15.0 >Reporter: Eyal Segal >Assignee: Julian Hyde >Priority: Major > > Vertica DB returns BigInteger values as BigInteger. It seems that > JavaToSqlTypeConversionRules doesn't support mapping between BigInteger to > BIGINT. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2046) Support "CREATE FUNCTION" DDL
[
https://issues.apache.org/jira/browse/CALCITE-2046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397769#comment-16397769
]
Shuyi Chen commented on CALCITE-2046:
-
Also keyword seems to be somehow reserved that I can't use for CREATE
LIBRARY. I will use instead. What do you think?
> Support "CREATE FUNCTION" DDL
> -
>
> Key: CALCITE-2046
> URL: https://issues.apache.org/jira/browse/CALCITE-2046
> Project: Calcite
> Issue Type: New Feature
>Reporter: Shuyi Chen
>Assignee: Shuyi Chen
>Priority: Major
>
> We want to add DDL support for creating external function like Apache Drill
> ([https://drill.apache.org/docs/create-function-using-jar/]).
> {code:java}
> CREATE FUNCTION USING JAR '.jar';
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2045) Support "CREATE TYPE" DDL
[ https://issues.apache.org/jira/browse/CALCITE-2045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397766#comment-16397766 ] Shuyi Chen commented on CALCITE-2045: - Hi [~julianhyde], do you think if we can get this in 1.16? Thanks a lot. > Support "CREATE TYPE" DDL > - > > Key: CALCITE-2045 > URL: https://issues.apache.org/jira/browse/CALCITE-2045 > Project: Calcite > Issue Type: New Feature > Components: core >Reporter: Shuyi Chen >Assignee: Shuyi Chen >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2211) Type of BigInteger should be BIGINT
[ https://issues.apache.org/jira/browse/CALCITE-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397750#comment-16397750 ] Shuyi Chen commented on CALCITE-2211: - Good point. java.math.BigInteger has unlimited decision, I dont think there is a sql type equivalent to it. The close I think is decimal. In JavaToSqlTypeConversionRules, we are mapping BigDecimal(unlimited precision) to Sql.Decimal already, so I think we can convert BigInteger to Sql.Decimal as well. Transact-SQL do conversion of integer to Decimal if it's outside the integer range. (https://docs.microsoft.com/en-us/sql/t-sql/data-types/int-bigint-smallint-and-tinyint-transact-sql#converting-integer-data > Type of BigInteger should be BIGINT > --- > > Key: CALCITE-2211 > URL: https://issues.apache.org/jira/browse/CALCITE-2211 > Project: Calcite > Issue Type: Bug >Affects Versions: 1.15.0 >Reporter: Eyal Segal >Assignee: Julian Hyde >Priority: Major > > Vertica DB returns BigInteger values as BigInteger. It seems that > JavaToSqlTypeConversionRules doesn't support mapping between BigInteger to > BIGINT. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2211) Type of BigInteger should be BIGINT
[ https://issues.apache.org/jira/browse/CALCITE-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397705#comment-16397705 ] Shuyi Chen commented on CALCITE-2211: - It seems we just need to add BigInteger to BIGINT conversion in the map. Do you have a unittest that fails? > Type of BigInteger should be BIGINT > --- > > Key: CALCITE-2211 > URL: https://issues.apache.org/jira/browse/CALCITE-2211 > Project: Calcite > Issue Type: Bug >Affects Versions: 1.15.0 >Reporter: Eyal Segal >Assignee: Julian Hyde >Priority: Major > > Vertica DB returns BigInteger values as BigInteger. It seems that > JavaToSqlTypeConversionRules doesn't support mapping between BigInteger to > BIGINT. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-2209) Support loading JSON model file through URL
Shuyi Chen created CALCITE-2209: --- Summary: Support loading JSON model file through URL Key: CALCITE-2209 URL: https://issues.apache.org/jira/browse/CALCITE-2209 Project: Calcite Issue Type: New Feature Components: core Reporter: Shuyi Chen Assignee: Shuyi Chen Currently, Calcite only support loading JSON model file through inline or local file. The Jira attemps to extend it to support loading JSON model file through URL, so users can implement their own URLStreamHandlerFactory to read the JSON model file from e.g., HDFS or etc. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2045) Support "CREATE TYPE" DDL
[ https://issues.apache.org/jira/browse/CALCITE-2045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16393765#comment-16393765 ] Shuyi Chen commented on CALCITE-2045: - Hi [~julianhyde], I addressed all comments, could you please take another look at the PR? Thanks a lot. > Support "CREATE TYPE" DDL > - > > Key: CALCITE-2045 > URL: https://issues.apache.org/jira/browse/CALCITE-2045 > Project: Calcite > Issue Type: New Feature > Components: core >Reporter: Shuyi Chen >Assignee: Shuyi Chen >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2046) Support "CREATE FUNCTION" DDL
[
https://issues.apache.org/jira/browse/CALCITE-2046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16383271#comment-16383271
]
Shuyi Chen commented on CALCITE-2046:
-
Hi [~julianhyde], similar to "CREATE TYPE", I am thinking maybe we need add
library into the JSON model as well, and keep the fullClassPath for each
library added, and this is used to remove all added functions when drop or
alter is invoked. What do you think?
> Support "CREATE FUNCTION" DDL
> -
>
> Key: CALCITE-2046
> URL: https://issues.apache.org/jira/browse/CALCITE-2046
> Project: Calcite
> Issue Type: New Feature
>Reporter: Shuyi Chen
>Assignee: Shuyi Chen
>Priority: Major
>
> We want to add DDL support for creating external function like Apache Drill
> ([https://drill.apache.org/docs/create-function-using-jar/]).
> {code:java}
> CREATE FUNCTION USING JAR '.jar';
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2045) Support "CREATE TYPE" DDL
[ https://issues.apache.org/jira/browse/CALCITE-2045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16379730#comment-16379730 ] Shuyi Chen edited comment on CALCITE-2045 at 2/28/18 8:25 AM: -- Hi [~julianhyde], initial [PR|https://github.com/apache/calcite/pull/638] is attached, could you please help take a look? was (Author: suez1224): [~julianhyde], initial [PR|https://github.com/apache/calcite/pull/638], could you please help take a look? > Support "CREATE TYPE" DDL > - > > Key: CALCITE-2045 > URL: https://issues.apache.org/jira/browse/CALCITE-2045 > Project: Calcite > Issue Type: New Feature > Components: core >Reporter: Shuyi Chen >Assignee: Shuyi Chen >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2045) Support "CREATE TYPE" DDL
[ https://issues.apache.org/jira/browse/CALCITE-2045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16379730#comment-16379730 ] Shuyi Chen commented on CALCITE-2045: - [~julianhyde], initial [PR|https://github.com/apache/calcite/pull/638], could you please help take a look? > Support "CREATE TYPE" DDL > - > > Key: CALCITE-2045 > URL: https://issues.apache.org/jira/browse/CALCITE-2045 > Project: Calcite > Issue Type: New Feature > Components: core >Reporter: Shuyi Chen >Assignee: Shuyi Chen >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2045) Support "CREATE TYPE" DDL
[ https://issues.apache.org/jira/browse/CALCITE-2045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16356429#comment-16356429 ] Shuyi Chen edited comment on CALCITE-2045 at 2/8/18 3:15 AM: - Hi [~julianhyde], I think I'll need to extend SqlDataTypeSpec to pass the schema (or something equivalence to provide access to the registered UDT) for SqlDataTypeSpec.deriveType(). Otherwise, after I create a type using "_CREATE TYPE mytype1 as int_", when I use the type to, say, _create table t (c mytype1),_ it will fail. Because the type info is only registered in the schema, and SqlDataTypeSpec has to access the created user-defined type through schema. However, this might be difficult because not all call sites of SqlDataTypeSpec.deriveType can provide access to the schema. If this is the right option, I can try to modify all call sites to provide access to the schema directly or indirectly. Do you have any suggestions? was (Author: suez1224): Hi [~julianhyde], I think I'll need to extend SqlDataTypeSpec to pass the schema (or something equivalence to provide access to the registered UDT) during SqlDataTypeSpec.deriveType call. Otherwise, after I create a type using "_CREATE TYPE mytype1 as int_", when I use the type to, say, _create table t (c mytype1),_ it will fail. Because the type info is only registered in the schema, and SqlDataTypeSpec has to access the created user-defined type through schema. However, this might be difficult because not all call sites of SqlDataTypeSpec.deriveType can provide access to the schema. If this is the right option, I can try to modify all call sites to provide access to the schema directly or indirectly. Do you have any suggestions? > Support "CREATE TYPE" DDL > - > > Key: CALCITE-2045 > URL: https://issues.apache.org/jira/browse/CALCITE-2045 > Project: Calcite > Issue Type: New Feature > Components: core >Reporter: Shuyi Chen >Assignee: Shuyi Chen >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2045) Support "CREATE TYPE" DDL
[ https://issues.apache.org/jira/browse/CALCITE-2045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16356429#comment-16356429 ] Shuyi Chen commented on CALCITE-2045: - Hi [~julianhyde], I think I'll need to extend SqlDataTypeSpec to pass the schema (or something equivalence to provide access to the registered UDT) during SqlDataTypeSpec.deriveType call. Otherwise, after I create a type using "_CREATE TYPE mytype1 as int_", when I use the type to, say, _create table t (c mytype1),_ it will fail. Because the type info is only registered in the schema, and SqlDataTypeSpec has to access the created user-defined type through schema. However, this might be difficult because not all call sites of SqlDataTypeSpec.deriveType can provide access to the schema. If this is the right option, I can try to modify all call sites to provide access to the schema directly or indirectly. Do you have any suggestions? > Support "CREATE TYPE" DDL > - > > Key: CALCITE-2045 > URL: https://issues.apache.org/jira/browse/CALCITE-2045 > Project: Calcite > Issue Type: New Feature > Components: core >Reporter: Shuyi Chen >Assignee: Shuyi Chen >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (CALCITE-2171) ExampleFunctionTest is not reading model.json
[ https://issues.apache.org/jira/browse/CALCITE-2171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shuyi Chen closed CALCITE-2171. --- Resolution: Won't Fix > ExampleFunctionTest is not reading model.json > -- > > Key: CALCITE-2171 > URL: https://issues.apache.org/jira/browse/CALCITE-2171 > Project: Calcite > Issue Type: Bug >Reporter: Shuyi Chen >Assignee: Shuyi Chen >Priority: Major > > ExampleFunctionTest is not reading model.json at all. I think we can either > remove it, or modify the code to read model.json. Please let me know. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2171) ExampleFunctionTest is not reading model.json
[ https://issues.apache.org/jira/browse/CALCITE-2171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16354858#comment-16354858 ] Shuyi Chen commented on CALCITE-2171: - I see, do we leave it there just for demonstration purpose? But it's confusing though when I was reading the code. I would suggest clone the test to both use SPI and model.json file. Otherwise, if ModelHandler.addFunctions breaks, we wont be able to catch it. But maybe there are other tests testing the code path that I am unaware of. What do you think? > ExampleFunctionTest is not reading model.json > -- > > Key: CALCITE-2171 > URL: https://issues.apache.org/jira/browse/CALCITE-2171 > Project: Calcite > Issue Type: Bug >Reporter: Shuyi Chen >Assignee: Shuyi Chen >Priority: Major > > ExampleFunctionTest is not reading model.json at all. I think we can either > remove it, or modify the code to read model.json. Please let me know. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-2171) [Cleanup] ExampleFunctionTest is not reading model.json
Shuyi Chen created CALCITE-2171: --- Summary: [Cleanup] ExampleFunctionTest is not reading model.json Key: CALCITE-2171 URL: https://issues.apache.org/jira/browse/CALCITE-2171 Project: Calcite Issue Type: Bug Reporter: Shuyi Chen Assignee: Shuyi Chen ExampleFunctionTest is not reading model.json at all. I think we can either remove it, or modify the code to read model.json. Please let me know. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2171) ExampleFunctionTest is not reading model.json
[ https://issues.apache.org/jira/browse/CALCITE-2171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shuyi Chen updated CALCITE-2171: Summary: ExampleFunctionTest is not reading model.json (was: [Cleanup] ExampleFunctionTest is not reading model.json ) > ExampleFunctionTest is not reading model.json > -- > > Key: CALCITE-2171 > URL: https://issues.apache.org/jira/browse/CALCITE-2171 > Project: Calcite > Issue Type: Bug >Reporter: Shuyi Chen >Assignee: Shuyi Chen >Priority: Major > > ExampleFunctionTest is not reading model.json at all. I think we can either > remove it, or modify the code to read model.json. Please let me know. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2167) Travis JDK9 test always fails
[ https://issues.apache.org/jira/browse/CALCITE-2167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shuyi Chen updated CALCITE-2167: Description: The test fails with the following lines at the end. /home/travis/.travis/job_stages: line 57: 3675 Killed mvn -Dsurefire.useFile=false -Dsurefire.parallel= test The command "mvn -Dsurefire.useFile=false -Dsurefire.parallel= test" exited with 137. cache.2 store build cache 0.06s 25.00schange detected (content changed, file is created, or file is deleted): /home/travis/.m2/repository/org/apache/calcite/calcite/1.16.0-SNAPSHOT/maven-metadata-local.xml /home/travis/.m2/repository/org/apache/calcite/calcite/1.16.0-SNAPSHOT/_remote.repositories /home/travis/.m2/repository/org/apache/calcite/calcite-cassandra/1.16.0-SNAPSHOT/calcite-cassandra-1.16.0-SNAPSHOT.jar /home/travis/.m2/repository/org/apache/calcite/calcite-cassandra/1.16.0-SNAPSHOT/calcite-cassandra-1.16.0-SNAPSHOT-sources.jar /home/travis/.m2/repository/org/apache/calcite/calcite-cassandra/1.16.0-SNAPSHOT/calcite-cassandra-1.16.0-SNAPSHOT-tests.jar /home/travis/.m2/repository/org/apache/calcite/calcite-cassandra/1.16.0-SNAPSHOT/calcite-cassandra-1.16.0-SNAPSHOT-test-sources.jar /home/travis/.m2/repository/org/apache/calcite/calcite-cassandra/1.16.0-SNAPSHOT/maven-metadata-local.xml /home/travis/.m2/repository/org/apache/calcite/calcite-cassandra/1.16.0-SNAPSHOT/_remote.repositories /home/travis/.m2/repository/org/apache/calcite/calcite-cassandra/maven-metadata-local.xml /home/travis ... changes detected, packing new archive . . uploading archive Done. Your build exited with 1. was: The test fails with the following lines at the end. /home/travis/.travis/job_stages: line 57: 3675 Killed mvn -Dsurefire.useFile=false -Dsurefire.parallel= test travis_time:end:0aec2e98:start=1517879428856882544,finish=1517879519701877528,duration=90844994984 [0K [31;1mThe command "mvn -Dsurefire.useFile=false -Dsurefire.parallel= test" exited with 137.[0m travis_fold:start:cache.2 [0Kstore build cache travis_time:start:2714903e [0K travis_time:end:2714903e:start=1517879519781154682,finish=1517879519841108137,duration=59953455 [0Ktravis_time:start:0f26b8a2 [0K[32;1mchange detected (content changed, file is created, or file is deleted): /home/travis/.m2/repository/org/apache/calcite/calcite/1.16.0-SNAPSHOT/maven-metadata-local.xml /home/travis/.m2/repository/org/apache/calcite/calcite/1.16.0-SNAPSHOT/_remote.repositories /home/travis/.m2/repository/org/apache/calcite/calcite-cassandra/1.16.0-SNAPSHOT/calcite-cassandra-1.16.0-SNAPSHOT.jar /home/travis/.m2/repository/org/apache/calcite/calcite-cassandra/1.16.0-SNAPSHOT/calcite-cassandra-1.16.0-SNAPSHOT-sources.jar /home/travis/.m2/repository/org/apache/calcite/calcite-cassandra/1.16.0-SNAPSHOT/calcite-cassandra-1.16.0-SNAPSHOT-tests.jar /home/travis/.m2/repository/org/apache/calcite/calcite-cassandra/1.16.0-SNAPSHOT/calcite-cassandra-1.16.0-SNAPSHOT-test-sources.jar /home/travis/.m2/repository/org/apache/calcite/calcite-cassandra/1.16.0-SNAPSHOT/maven-metadata-local.xml /home/travis/.m2/repository/org/apache/calcite/calcite-cassandra/1.16.0-SNAPSHOT/_remote.repositories /home/travis/.m2/repository/org/apache/calcite/calcite-cassandra/maven-metadata-local.xml /home/travis [0m [32;1m... [0m [32;1mchanges detected, packing new archive[0m . . [32;1muploading archive[0m travis_time:end:0f26b8a2:start=1517879519866099593,finish=1517879544868993271,duration=25002893678 [0Ktravis_fold:end:cache.2 [0K Done. Your build exited with 1. > Travis JDK9 test always fails > - > > Key: CALCITE-2167 > URL: https://issues.apache.org/jira/browse/CALCITE-2167 > Project: Calcite > Issue Type: Bug >Reporter: Shuyi Chen >Assignee: Julian Hyde >Priority: Major > > The test fails with the following lines at the end. > > > /home/travis/.travis/job_stages: line 57: 3675 Killed mvn > -Dsurefire.useFile=false -Dsurefire.parallel= test > > > The command "mvn -Dsurefire.useFile=false -Dsurefire.parallel= test" exited > with 137. > cache.2 > store build cache > 0.06s > 25.00schange detected (content changed, file is created, or file is deleted): > /home/travis/.m2/repository/org/apache/calcite/calcite/1.16.0-SNAPSHOT/maven-metadata-local.xml > /home/travis/.m2/repository/org/apache/calcite/calcite/1.16.0-SNAPSHOT/_remote.repositories > /home/travis/.m2/repository/org/apache/calcite/calcite-cassandra/1.16.0-SNAPSHOT/calcite-cassandra-1.16.0-SNAPSHOT.jar > /home/travis/.m2/repository/org/apache/calcite/calcite-cassandra/1.16.0-SNAPSHOT/calcite-cassandra-1.16.0-SNAPSHOT-sources.jar > /home/travis/.m2/repository/org/apache/calcite/calcite-cassandra/1.16.0-SNAPSHOT/calcite-cassandra-1.16.0-SNAPSHOT-tests.jar >
[jira] [Created] (CALCITE-2167) Travis JDK9 test always fails
Shuyi Chen created CALCITE-2167: --- Summary: Travis JDK9 test always fails Key: CALCITE-2167 URL: https://issues.apache.org/jira/browse/CALCITE-2167 Project: Calcite Issue Type: Bug Reporter: Shuyi Chen Assignee: Julian Hyde The test fails with the following lines at the end. /home/travis/.travis/job_stages: line 57: 3675 Killed mvn -Dsurefire.useFile=false -Dsurefire.parallel= test travis_time:end:0aec2e98:start=1517879428856882544,finish=1517879519701877528,duration=90844994984 [0K [31;1mThe command "mvn -Dsurefire.useFile=false -Dsurefire.parallel= test" exited with 137.[0m travis_fold:start:cache.2 [0Kstore build cache travis_time:start:2714903e [0K travis_time:end:2714903e:start=1517879519781154682,finish=1517879519841108137,duration=59953455 [0Ktravis_time:start:0f26b8a2 [0K[32;1mchange detected (content changed, file is created, or file is deleted): /home/travis/.m2/repository/org/apache/calcite/calcite/1.16.0-SNAPSHOT/maven-metadata-local.xml /home/travis/.m2/repository/org/apache/calcite/calcite/1.16.0-SNAPSHOT/_remote.repositories /home/travis/.m2/repository/org/apache/calcite/calcite-cassandra/1.16.0-SNAPSHOT/calcite-cassandra-1.16.0-SNAPSHOT.jar /home/travis/.m2/repository/org/apache/calcite/calcite-cassandra/1.16.0-SNAPSHOT/calcite-cassandra-1.16.0-SNAPSHOT-sources.jar /home/travis/.m2/repository/org/apache/calcite/calcite-cassandra/1.16.0-SNAPSHOT/calcite-cassandra-1.16.0-SNAPSHOT-tests.jar /home/travis/.m2/repository/org/apache/calcite/calcite-cassandra/1.16.0-SNAPSHOT/calcite-cassandra-1.16.0-SNAPSHOT-test-sources.jar /home/travis/.m2/repository/org/apache/calcite/calcite-cassandra/1.16.0-SNAPSHOT/maven-metadata-local.xml /home/travis/.m2/repository/org/apache/calcite/calcite-cassandra/1.16.0-SNAPSHOT/_remote.repositories /home/travis/.m2/repository/org/apache/calcite/calcite-cassandra/maven-metadata-local.xml /home/travis [0m [32;1m... [0m [32;1mchanges detected, packing new archive[0m . . [32;1muploading archive[0m travis_time:end:0f26b8a2:start=1517879519866099593,finish=1517879544868993271,duration=25002893678 [0Ktravis_fold:end:cache.2 [0K Done. Your build exited with 1. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2161) Add "types" collection to the schema element in the JSON model
[ https://issues.apache.org/jira/browse/CALCITE-2161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16353201#comment-16353201 ] Shuyi Chen commented on CALCITE-2161: - Hi [~julianhyde], added a PR. jdk8 test passes, but jdk9 test still fails with similar output. Could you please take a look at your convenience? Thanks. > Add "types" collection to the schema element in the JSON model > -- > > Key: CALCITE-2161 > URL: https://issues.apache.org/jira/browse/CALCITE-2161 > Project: Calcite > Issue Type: Task > Components: core >Affects Versions: 1.16.0 >Reporter: Shuyi Chen >Assignee: Shuyi Chen >Priority: Major > > As discussed in CALCITE-2045, we need to add "types" collection in the schema > element in the JSON model. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (CALCITE-2046) Support "CREATE FUNCTION" DDL
[
https://issues.apache.org/jira/browse/CALCITE-2046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shuyi Chen reassigned CALCITE-2046:
---
Assignee: Shuyi Chen (was: Julian Hyde)
> Support "CREATE FUNCTION" DDL
> -
>
> Key: CALCITE-2046
> URL: https://issues.apache.org/jira/browse/CALCITE-2046
> Project: Calcite
> Issue Type: New Feature
>Reporter: Shuyi Chen
>Assignee: Shuyi Chen
>Priority: Major
>
> We want to add DDL support for creating external function like Apache Drill
> ([https://drill.apache.org/docs/create-function-using-jar/]).
> {code:java}
> CREATE FUNCTION USING JAR '.jar';
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (CALCITE-2045) Support "CREATE TYPE" DDL
[ https://issues.apache.org/jira/browse/CALCITE-2045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shuyi Chen reassigned CALCITE-2045: --- Assignee: Shuyi Chen (was: Julian Hyde) > Support "CREATE TYPE" DDL > - > > Key: CALCITE-2045 > URL: https://issues.apache.org/jira/browse/CALCITE-2045 > Project: Calcite > Issue Type: New Feature > Components: core >Reporter: Shuyi Chen >Assignee: Shuyi Chen >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (CALCITE-2161) Add "types" collection to the schema element in the JSON model
[ https://issues.apache.org/jira/browse/CALCITE-2161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shuyi Chen reassigned CALCITE-2161: --- Assignee: Shuyi Chen (was: Julian Hyde) > Add "types" collection to the schema element in the JSON model > -- > > Key: CALCITE-2161 > URL: https://issues.apache.org/jira/browse/CALCITE-2161 > Project: Calcite > Issue Type: Task > Components: core >Affects Versions: 1.16.0 >Reporter: Shuyi Chen >Assignee: Shuyi Chen >Priority: Major > > As discussed in CALCITE-2045, we need to add "types" collection in the schema > element in the JSON model. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2162) Exception when accessing subfield of subfield of composite Array element
[
https://issues.apache.org/jira/browse/CALCITE-2162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16351959#comment-16351959
]
Shuyi Chen commented on CALCITE-2162:
-
Thanks, I tried to run _mvn test_ on local machine with jdk-9.0.4, and it
passes. Could you please review it again?
Also, can you grant me contributor permission on JIRA, so I can assign those
pending tickets to myself.
> Exception when accessing subfield of subfield of composite Array element
>
>
> Key: CALCITE-2162
> URL: https://issues.apache.org/jira/browse/CALCITE-2162
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.15.0
>Reporter: Shuyi Chen
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.16.0
>
>
> for example, the following expression will throw an exception:
> {code:java}
> a[1].b.c{code}
> but the following will work:
> {code:java}
> a[1].b{code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2045) Support "CREATE TYPE" DDL
[
https://issues.apache.org/jira/browse/CALCITE-2045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16351203#comment-16351203
]
Shuyi Chen commented on CALCITE-2045:
-
Hi [~julianhyde], shall we also extend SqlDataTypeSpec and the parser to
support complex type expressions like:
{code:java}
ROW(NUMBER(5, 2) NOT NULL AS foo, ROW(BOOLEAN AS b, MyUDT NOT NULL AS i) AS rec)
{code}
However, the grammar might be slightly different than the grammar in what we
discussed above in "CREATE TYPE", i.e.,
{code:java}
CREATE TYPE myType AS (b BOOLEAN, i MyUDT NOT NULL)
CREATE TYPE myType2 AS (foo NUMBER(5, 2) NOT NULL, rec myType){code}
Should we converge them, or leave them as 2 different parser implementations?
Thanks a lot.
> Support "CREATE TYPE" DDL
> -
>
> Key: CALCITE-2045
> URL: https://issues.apache.org/jira/browse/CALCITE-2045
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Reporter: Shuyi Chen
>Assignee: Julian Hyde
>Priority: Major
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2162) Exception when accessing subfield of subfield of composite Array element
[
https://issues.apache.org/jira/browse/CALCITE-2162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16350033#comment-16350033
]
Shuyi Chen commented on CALCITE-2162:
-
Hi, [~julianhyde], I've fixed the tests, but the jdk9 build is still failing,
the log is not useful and I can't replicate the failure on my local machine
either. Could you please help take a look?
> Exception when accessing subfield of subfield of composite Array element
>
>
> Key: CALCITE-2162
> URL: https://issues.apache.org/jira/browse/CALCITE-2162
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.15.0
>Reporter: Shuyi Chen
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.16.0
>
>
> for example, the following expression will throw an exception:
> {code:java}
> a[1].b.c{code}
> but the following will work:
> {code:java}
> a[1].b{code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2162) Exception when accessing subfield of subfield of composite Array element
[
https://issues.apache.org/jira/browse/CALCITE-2162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16349575#comment-16349575
]
Shuyi Chen commented on CALCITE-2162:
-
[~julianhyde], done.
> Exception when accessing subfield of subfield of composite Array element
>
>
> Key: CALCITE-2162
> URL: https://issues.apache.org/jira/browse/CALCITE-2162
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.15.0
>Reporter: Shuyi Chen
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.16.0
>
>
> for example, the following expression will throw an exception:
> {code:java}
> a[1].b.c{code}
> but the following will work:
> {code:java}
> a[1].b{code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2162) Exception when accessing subfield of subfield of composite Array element
[
https://issues.apache.org/jira/browse/CALCITE-2162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shuyi Chen updated CALCITE-2162:
Description:
for example, the following expression will throw an exception:
{code:java}
a[1].b.c{code}
but the following will work:
{code:java}
a[1].b{code}
Summary: Exception when accessing subfield of subfield of composite
Array element (was: SqlValidatorImpl.stripDot should be recursive)
> Exception when accessing subfield of subfield of composite Array element
>
>
> Key: CALCITE-2162
> URL: https://issues.apache.org/jira/browse/CALCITE-2162
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.15.0
>Reporter: Shuyi Chen
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.16.0
>
>
> for example, the following expression will throw an exception:
> {code:java}
> a[1].b.c{code}
> but the following will work:
> {code:java}
> a[1].b{code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2162) SqlValidatorImpl.stripDot should be recursive
[ https://issues.apache.org/jira/browse/CALCITE-2162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16349445#comment-16349445 ] Shuyi Chen commented on CALCITE-2162: - Hi [~julianhyde], PR is attached, can you help take a look? Thanks. > SqlValidatorImpl.stripDot should be recursive > - > > Key: CALCITE-2162 > URL: https://issues.apache.org/jira/browse/CALCITE-2162 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.15.0 >Reporter: Shuyi Chen >Assignee: Julian Hyde >Priority: Major > Fix For: 1.16.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-2162) SqlValidatorImpl.stripDot should be recursive
Shuyi Chen created CALCITE-2162: --- Summary: SqlValidatorImpl.stripDot should be recursive Key: CALCITE-2162 URL: https://issues.apache.org/jira/browse/CALCITE-2162 Project: Calcite Issue Type: Bug Components: core Affects Versions: 1.15.0 Reporter: Shuyi Chen Assignee: Julian Hyde Fix For: 1.16.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-2161) Add "types" collection to the schema element in the JSON model
Shuyi Chen created CALCITE-2161: --- Summary: Add "types" collection to the schema element in the JSON model Key: CALCITE-2161 URL: https://issues.apache.org/jira/browse/CALCITE-2161 Project: Calcite Issue Type: Task Components: core Affects Versions: 1.16.0 Reporter: Shuyi Chen Assignee: Julian Hyde As discussed in CALCITE-2045, we need to add "types" collection in the schema element in the JSON model. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (CALCITE-2149) RexSimplify throws indexOutOfBoundException
[ https://issues.apache.org/jira/browse/CALCITE-2149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shuyi Chen closed CALCITE-2149. --- Resolution: Fixed > RexSimplify throws indexOutOfBoundException > --- > > Key: CALCITE-2149 > URL: https://issues.apache.org/jira/browse/CALCITE-2149 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.15.0 >Reporter: Shuyi Chen >Assignee: Julian Hyde >Priority: Blocker > Fix For: 1.16.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-2149) RexSimplify throws indexOutOfBoundException
Shuyi Chen created CALCITE-2149: --- Summary: RexSimplify throws indexOutOfBoundException Key: CALCITE-2149 URL: https://issues.apache.org/jira/browse/CALCITE-2149 Project: Calcite Issue Type: Bug Components: core Affects Versions: 1.15.0 Reporter: Shuyi Chen Assignee: Julian Hyde Fix For: 1.16.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2133) Allow SqlGroupedWindowFunction to specify returnTypeInference in its constructor
[ https://issues.apache.org/jira/browse/CALCITE-2133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16328182#comment-16328182 ] Shuyi Chen commented on CALCITE-2133: - Thanks a lot for the review, [~julianhyde]. Could you please help take another look at the [PR|https://github.com/apache/calcite/pull/606]? > Allow SqlGroupedWindowFunction to specify returnTypeInference in its > constructor > > > Key: CALCITE-2133 > URL: https://issues.apache.org/jira/browse/CALCITE-2133 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.16.0 >Reporter: Shuyi Chen >Assignee: Julian Hyde >Priority: Major > Fix For: 1.16.0 > > > This is follow-up of CALCITE-1867; we need to add a new constructor to allow > Flink to pass in the returnTypeInference parameter. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2133) Allow SqlGroupedWindowFunction to specify returnTypeInference in its constructor
[ https://issues.apache.org/jira/browse/CALCITE-2133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16324916#comment-16324916 ] Shuyi Chen commented on CALCITE-2133: - Hi [~julianhyde], please let me know what you think. Here is the [PR|https://github.com/apache/calcite/pull/606]. > Allow SqlGroupedWindowFunction to specify returnTypeInference in its > constructor > > > Key: CALCITE-2133 > URL: https://issues.apache.org/jira/browse/CALCITE-2133 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.16.0 >Reporter: Shuyi Chen >Assignee: Julian Hyde > Fix For: 1.16.0 > > > This is follow-up of > [Calcite-1867|https://issues.apache.org/jira/browse/CALCITE-1867], we need > toy add a new constructor to allow Flink to pass in the returnTypeInference > parameter. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CALCITE-2133) Allow SqlGroupedWindowFunction to specify returnTypeInference in its constructor
Shuyi Chen created CALCITE-2133: --- Summary: Allow SqlGroupedWindowFunction to specify returnTypeInference in its constructor Key: CALCITE-2133 URL: https://issues.apache.org/jira/browse/CALCITE-2133 Project: Calcite Issue Type: Improvement Components: core Affects Versions: 1.16.0 Reporter: Shuyi Chen Assignee: Julian Hyde Fix For: 1.16.0 This is follow-up of [Calcite-1867|https://issues.apache.org/jira/browse/CALCITE-1867], we need toy add a new constructor to allow Flink to pass in the returnTypeInference parameter. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (CALCITE-2046) Support "CREATE FUNCTION" DDL
[
https://issues.apache.org/jira/browse/CALCITE-2046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16272218#comment-16272218
]
Shuyi Chen edited comment on CALCITE-2046 at 11/30/17 6:20 AM:
---
Hi [~julianhyde], do you have any thought on the syntax?
was (Author: suez1224):
Hi [~julianhyde], any thought on this?
> Support "CREATE FUNCTION" DDL
> -
>
> Key: CALCITE-2046
> URL: https://issues.apache.org/jira/browse/CALCITE-2046
> Project: Calcite
> Issue Type: New Feature
>Reporter: Shuyi Chen
>Assignee: Julian Hyde
>
> We want to add DDL support for creating external function like Apache Drill
> ([https://drill.apache.org/docs/create-function-using-jar/]).
> {code:java}
> CREATE FUNCTION USING JAR '.jar';
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (CALCITE-2046) Support "CREATE FUNCTION" DDL
[
https://issues.apache.org/jira/browse/CALCITE-2046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shuyi Chen updated CALCITE-2046:
Description:
We want to add DDL support for creating external function like Apache Drill
([https://drill.apache.org/docs/create-function-using-jar/]).
{code:java}
CREATE FUNCTION USING JAR '.jar';
{code}
> Support "CREATE FUNCTION" DDL
> -
>
> Key: CALCITE-2046
> URL: https://issues.apache.org/jira/browse/CALCITE-2046
> Project: Calcite
> Issue Type: New Feature
>Reporter: Shuyi Chen
>Assignee: Julian Hyde
>
> We want to add DDL support for creating external function like Apache Drill
> ([https://drill.apache.org/docs/create-function-using-jar/]).
> {code:java}
> CREATE FUNCTION USING JAR '.jar';
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-2046) Support "CREATE FUNCTION" DDL
[
https://issues.apache.org/jira/browse/CALCITE-2046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16272218#comment-16272218
]
Shuyi Chen commented on CALCITE-2046:
-
Hi [~julianhyde], any thought on this?
> Support "CREATE FUNCTION" DDL
> -
>
> Key: CALCITE-2046
> URL: https://issues.apache.org/jira/browse/CALCITE-2046
> Project: Calcite
> Issue Type: New Feature
>Reporter: Shuyi Chen
>Assignee: Julian Hyde
>
> We want to add DDL support for creating external function like Apache Drill
> ([https://drill.apache.org/docs/create-function-using-jar/]).
> {code:java}
> CREATE FUNCTION USING JAR '.jar';
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-2045) Support "CREATE TYPE" DDL
[ https://issues.apache.org/jira/browse/CALCITE-2045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16272210#comment-16272210 ] Shuyi Chen commented on CALCITE-2045: - Thanks, [~julianhyde]. I saw CALCITE-707 is resolved. I will work on adding the "CREATE TYPE" DDL on top of it. > Support "CREATE TYPE" DDL > - > > Key: CALCITE-2045 > URL: https://issues.apache.org/jira/browse/CALCITE-2045 > Project: Calcite > Issue Type: New Feature > Components: core >Reporter: Shuyi Chen >Assignee: Julian Hyde > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-2045) Support "CREATE TYPE" DDL
[ https://issues.apache.org/jira/browse/CALCITE-2045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16256078#comment-16256078 ] Shuyi Chen commented on CALCITE-2045: - Thanks, [~julianhyde]. I think that looks good to me as the first version. Are you planning to add it in Calcite-707 or we can implement it after it? > Support "CREATE TYPE" DDL > - > > Key: CALCITE-2045 > URL: https://issues.apache.org/jira/browse/CALCITE-2045 > Project: Calcite > Issue Type: New Feature > Components: core >Reporter: Shuyi Chen >Assignee: Julian Hyde > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-2045) Support "CREATE TYPE" DDL
[
https://issues.apache.org/jira/browse/CALCITE-2045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16253119#comment-16253119
]
Shuyi Chen commented on CALCITE-2045:
-
Hi [~julianhyde], I think we can start with the following syntax to allow
creating scalar type and composite(row) type
CREATE TYPE [ schema_name. ] type_name
{
FROM base_type
[ NULL | NOT NULL ]
| AS ( [ attribute_name [ COLLATE collation ] [ NULL | NOT NULL ]
[ ,...n ] )
} [ ; ]
What do you think?
> Support "CREATE TYPE" DDL
> -
>
> Key: CALCITE-2045
> URL: https://issues.apache.org/jira/browse/CALCITE-2045
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Reporter: Shuyi Chen
>Assignee: Julian Hyde
>
--
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=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] [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] [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] [Comment Edited] (CALCITE-2045) Support "CREATE TYPE" DDL
[ https://issues.apache.org/jira/browse/CALCITE-2045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16248028#comment-16248028 ] Shuyi Chen edited comment on CALCITE-2045 at 11/10/17 9:09 PM: --- Hi [~julianhyde], what do you think of supporting this in Calcite DDL? Or is it better to extend the parser in the project itself similar to Drill? was (Author: suez1224): Hi [~julianhyde], what do you think of supporting this in Calcite DDL? > Support "CREATE TYPE" DDL > - > > Key: CALCITE-2045 > URL: https://issues.apache.org/jira/browse/CALCITE-2045 > Project: Calcite > Issue Type: New Feature > Components: core >Reporter: Shuyi Chen >Assignee: Julian Hyde > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (CALCITE-2046) Support "CREATE FUNCTION" DDL
[ https://issues.apache.org/jira/browse/CALCITE-2046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16248030#comment-16248030 ] Shuyi Chen edited comment on CALCITE-2046 at 11/10/17 9:09 PM: --- Hi [~julianhyde], what do you think of supporting this in Calcite DDL? Or is it better to extend the parser in the project itself similar to Drill? was (Author: suez1224): Hi [~julianhyde], what do you think of supporting this in Calcite DDL? > Support "CREATE FUNCTION" DDL > - > > Key: CALCITE-2046 > URL: https://issues.apache.org/jira/browse/CALCITE-2046 > Project: Calcite > Issue Type: New Feature >Reporter: Shuyi Chen >Assignee: Julian Hyde > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-2046) Support "CREATE FUNCTION" DDL
[ https://issues.apache.org/jira/browse/CALCITE-2046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16248030#comment-16248030 ] Shuyi Chen commented on CALCITE-2046: - Hi [~julianhyde], what do you think of supporting this in Calcite DDL? > Support "CREATE FUNCTION" DDL > - > > Key: CALCITE-2046 > URL: https://issues.apache.org/jira/browse/CALCITE-2046 > Project: Calcite > Issue Type: New Feature >Reporter: Shuyi Chen >Assignee: Julian Hyde > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
