[
https://issues.apache.org/jira/browse/CALCITE-1208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15427099#comment-15427099
]
Maryann Xue commented on CALCITE-1208:
--------------------------------------
I can repo the issue with a Calcite test case below. The validation is good,
but the exception occurred in SqlToRelConverter.
{code}
--- a/core/src/test/java/org/apache/calcite/test/SqlToRelConverterTest.java
+++ b/core/src/test/java/org/apache/calcite/test/SqlToRelConverterTest.java
@@ -1709,6 +1709,9 @@ protected final void check(
@Test public void testStructType() {
sql("select * from struct.t").convertsTo("${plan}");
+
+ // Resolve F1.C2 as fully qualified column F1.C2.
+ sql("select f1.c2 from struct.t").convertsTo("${plan}");;
}
/**
{code}
The IndexOutOfBoundException I got:
{code}
java.lang.IndexOutOfBoundsException: index (-1) must not be negative
at
com.google.common.base.Preconditions.checkElementIndex(Preconditions.java:310)
at
com.google.common.base.Preconditions.checkElementIndex(Preconditions.java:292)
at
com.google.common.collect.RegularImmutableList.get(RegularImmutableList.java:65)
at org.apache.calcite.util.Util.last(Util.java:2022)
at
org.apache.calcite.sql.validate.ListScope.findChild(ListScope.java:74)
at org.apache.calcite.sql.validate.ListScope.resolve(ListScope.java:166)
at
org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.lookupExp(SqlToRelConverter.java:3879)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertIdentifier(SqlToRelConverter.java:3248)
at
org.apache.calcite.sql2rel.SqlToRelConverter.access$4(SqlToRelConverter.java:3233)
at
org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:4271)
at
org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:1)
at org.apache.calcite.sql.SqlIdentifier.accept(SqlIdentifier.java:324)
at
org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:4152)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectList(SqlToRelConverter.java:3465)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:665)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:622)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:2841)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:556)
at
org.apache.calcite.test.SqlToRelTestBase$TesterImpl.convertSqlToRel(SqlToRelTestBase.java:541)
at
org.apache.calcite.test.SqlToRelTestBase$TesterImpl.assertConvertsTo(SqlToRelTestBase.java:649)
at
org.apache.calcite.test.SqlToRelConverterTest$Sql.convertsTo(SqlToRelConverterTest.java:1932)
at
org.apache.calcite.test.SqlToRelConverterTest.testStructType(SqlToRelConverterTest.java:1714)
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:497)
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.runners.ParentRunner.run(ParentRunner.java:363)
at
org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
{code}
> Improve two-level column structure handling
> -------------------------------------------
>
> Key: CALCITE-1208
> URL: https://issues.apache.org/jira/browse/CALCITE-1208
> Project: Calcite
> Issue Type: Improvement
> Components: core
> Affects Versions: 1.7.0
> Reporter: Maryann Xue
> Assignee: Julian Hyde
> Labels: phoenix
> Fix For: 1.9.0
>
>
> Calcite now has support for nested column structure in parsing and
> validation, by representing the inner-level columns as a RexFieldAccess based
> on a RexInputRef. Meanwhile it does not flatten the inner level structure in
> wildcard expansion, which would then cause an UnsupportedOperationException
> in Avatica.
>
> The idea is to take into account this nested structure in column resolving,
> but to flatten the structure when translating to RelNode/RexNode.
> For example, if the table structure is defined as
> {code}VARCHAR K0,
> VARCHAR C1,
> RecordType(INTEGER C0, INTEGER C1) F0,
> RecordType(INTEGER C0, INTEGER C2) F1{code}
> , it should be viewed as a flat type like
> {code}VARCHAR K0,
> VARCHAR C1,
> INTEGER F0.C0,
> INTEGER F0.C1,
> INTEGER F1.C0,
> INTEGER F1.C2{code}
> , so that:
> 1) Column reference "K0" is translated as {{$0}}
> 2) Column reference "F0.C1" is translated as {{$3}}
> 3) Wildcard "*" is translated as: {{$0, $1, $2, $3, $4, $5}}
> 4) Complex-column wildcard "F1.*", which is translated as {{$2, $3}}
> And we would like to resolve columns based on the following rules (here we
> only consider the "suffix" part of the qualified names, which means the table
> resolving is already done by this time):
> a) A two-part column name is matched with its first-level column name and its
> second-level column name. For example, "F1.C0" corresponds to $4; "F1,X" will
> throw a column not found error.
> b) A single-part column name is matched against non-nested columns first, and
> if no matches, it is then matched against those second-level column names.
> For example, "C1" will be matched as "$1" instead of "$3", since non-nested
> columns have a higher priority; "C2" will be matched as "$5"; "C0" will lead
> to an ambiguous column error, since it exists under both "F0" and "F1".
> c) We would also like to have a way for defining "default first-level column"
> so that it has a precedence in column resolving over other first-level
> columns. For example, if "F0" is defined as default, "C0" will not cause an
> ambiguous column error, but instead be matched as "$2".
> d) Reference to first-level column only without wildcard is not allowed,
> e.g., "F1".
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
