[
https://issues.apache.org/jira/browse/CALCITE-2404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16602455#comment-16602455
]
Vladimir Sitnikov commented on CALCITE-2404:
--------------------------------------------
1) Re "phystype for structs", it would indeed be cool to have some kind of API
so "Enumerable" could know in advance what storage type is used to store column
(and its components).
Note: I do not know how to wrap my mind around that yet, however I think
something like {{InputGetter}} could suit
In other words:
org.apache.calcite.adapter.enumerable.EnumerableRel.Result stores
"blockstatement" (code that produces the results), "physType/format" (Java
representation of the result row).
AFAIK, there are methods that look like exactly to get "phystype of a subfield".
[~zabetak], have you checked if they work?
Currently org.apache.calcite.runtime.SqlFunctions#structAccess performs dynamic
lookup of a statically known fields.
Even though it might look like "a performance-only issue", it is a functional
issue as well, as it declares type-less API "we will decode any type you
provide even if every row has different row format". That looks odd.
{code:java}
PhysType {
...
/** Returns the physical type of a field. */
PhysType field(int ordinal);
/** Returns the physical type of a given field's component type. */
PhysType component(int field);
{code}
Note: even though this might sound like "let's build ideal solution that would
take 100500 years to implement", it does look like all the required machinery
is already there.
2) SqlFunctions#structAccess uses {{Class#getDeclaredField}} while
{{JavaTypeFactoryImpl}} uses {{Class#getFields()}}. That is a mis-match, and we
must not allow such code into the repository. Note: Ideally I would like to
have a case when {{SqlFunctions#structAccess}} is not required at all, however
I am not sure if it can be made in a simple way or not. For instance, I do not
yet clearly understand how "JDBC to Enumerable" should convert structs :)
> Accessing structured-types is not implemented by the runtime
> ------------------------------------------------------------
>
> Key: CALCITE-2404
> URL: https://issues.apache.org/jira/browse/CALCITE-2404
> Project: Calcite
> Issue Type: Bug
> Components: core
> Affects Versions: 1.17.0
> Reporter: Stamatis Zampetakis
> Assignee: Julian Hyde
> Priority: Blocker
>
> Queries on tables containing structured types cannot be executed by the
> Calcite runtime. A plan like the one that follows (taken from CALCITE-2220)
> can be translated to neither Bindable nor EnumerableConvention.
>
> {noformat}
> 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]])
> {noformat}
>
> More precisely, if a logical plan contains a RexFieldAccess expression that
> does not refer to a RexCorrelVariable it cannot be handled by the
> RexToLixTranslator. The translation will fail when calling
> [RexToLixTranslator#translate0|[https://github.com/apache/calcite/blob/5bbc501a565494442784f65870a20cd65a5016f4/core/src/main/java/org/apache/calcite/adapter/enumerable/RexToLixTranslator.java#L686]].
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
