You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@calcite.apache.org by "Stamatis Zampetakis (JIRA)" <ji...@apache.org> on 2018/07/07 12:57:00 UTC

[jira] [Commented] (CALCITE-2404) Accessing structured-types is not implemented by the runtime

    [ https://issues.apache.org/jira/browse/CALCITE-2404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16535752#comment-16535752 ] 

Stamatis Zampetakis commented on CALCITE-2404:
----------------------------------------------

I am a bit surprised that I bumped into this. Since I am putting together a custom planning process I was wondering if I am possibly missing an step in the planning process.

If it is indeed a bug then it is a bit weird that I am the first to notice it.

Does this mean that nobody else uses structured types in their model or do everybody implement projections and selections in their own custom Convention?

> 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)