[
https://issues.apache.org/jira/browse/CALCITE-3977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17106399#comment-17106399
]
Ruben Q L commented on CALCITE-3977:
------------------------------------
Looking inside RelDecorrelator code, it seems that this use case (a correlation
variable with several field accesses) is not supported.
The main classes inside RelDecorrelator to identify / reference a correlation
(CorRef and CorDef) are based on a:
{code}
public final CorrelationId corr;
public final int field;
{code}
For my examples, I am considering the Bookstoreschema:
{code}
public static class Author {
public final int aid;
public final String name;
public final Place birthPlace;
...
}
public static class Place {
public final Coordinate coords;
public final String city;
public final String country;
...
}
{code}
The RelDecorrelator approach works fine to decorrelate plans which use for
example {{$cor0.name}}, where we will have {{CorrelationId=$cor0}} and
{{field=1}}, i.e. {{$cor0.1}}.
However, in plans like the one described in this ticket, using
{{$cor0.birthPlace.city}}, this is not enough. It seems that the {{int field}}
would require to be a list (or array), so that we can have a CorRef / CorDef
with several "layers", i.e. {{$cor0.2.1}}. Right now these scenarios are not
correctly handled, hence the current bug.
Maybe [~julianhyde] (who seems the main contributor to the RelDecorrelator),
can confirm my assumption, and suggest an approach (maybe, as I proposed,
changing {{int field}} into {{int[] fields}} ?) in order to improve this module
to support this scenario.
> RelDecorrelator does not resolve correlation variable with field accesses
> -------------------------------------------------------------------------
>
> Key: CALCITE-3977
> URL: https://issues.apache.org/jira/browse/CALCITE-3977
> Project: Calcite
> Issue Type: Bug
> Components: core
> Affects Versions: 1.22.0
> Reporter: Thomas Rebele
> Priority: Major
> Attachments: Calcite3977.java
>
>
> The RelCorrelator seems to have problems with some plans that contain a field
> access (probably a RexFieldAccess, but I haven't looked further into it). In
> this ticket there's a filter on *$cor0.birthPlace.city*.
> Here the complete plan:
> {code:java}
> before decorrelate
> LogicalCorrelate(correlation=[$cor0], joinType=[left], requiredColumns=[{}])
> LogicalTableScan(table=[[bookstore, authors]])
> LogicalFilter(condition=[=('Munich', $cor0.birthPlace.city)])
> LogicalTableScan(table=[[bookstore, authors]])
> after decorrelate
> LogicalJoin(condition=[=($2, $8)], joinType=[left])
> LogicalTableScan(table=[[bookstore, authors]])
> LogicalJoin(condition=[true], joinType=[inner])
> LogicalFilter(condition=[=('Munich', $cor0.birthPlace.city)])
> LogicalTableScan(table=[[bookstore, authors]])
> LogicalAggregate(group=[{0}])
> LogicalProject(birthPlace=[$2])
> LogicalTableScan(table=[[bookstore, authors]])
> {code}
> There seem to be two problems:
> * The LogicalCorrelate has been removed, but the $cor0.birthPlace.city is
> still in the filter condition.
> * The inner join does not seem to be necessary. If it is, could somebody
> explain, why?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
