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/08/01 10:37: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=16565109#comment-16565109 ] 

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

 I think it is relevant to discuss a bit more the changes around the DOT operator.

According to its documentation "The dot operator is used to access a field of a record." So a RexCall with a DOT operator is another way to model field access without using the RexFieldAccess node. Without considering my changes we might obtain plans that contain both to achieve the same purpose. 

The test SqlToRelConverterTest.testArrayOfRecord is an example where the DOT operator is used to model field access.

In my opinion, we shouldn't have two ways of performing the same thing. In that direction, I am trying to make the DOT operator disappear from the plan. However, this affects *backward compatibility* since plans that contained a RexCall with the DOT operator will be now replaced with a RexFieldAccess. Essentially, existing clients which go from logical to physical plans may fail because of this new interpretation. 

Fixing the test depends on if we want to incorporate or not the change above:
 * if YES, then I have to modify the RelStructuredTypeFlattener
 * if NO, then I have to modify the RexToLixTranslator

+Note+: currently the flattener does not do any particular handling of a RexCall with a DOT operator (it just rewrites the call as is).

 

 

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