phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Maryann Xue (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (PHOENIX-1854) Investigate not setting ProjectedColumnExpression in TupleProjector expressions array
Date Tue, 26 Jan 2016 22:30:39 GMT

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

Maryann Xue commented on PHOENIX-1854:
--------------------------------------

I looked into it and found that the code you pointed out was exactly a bug. There was no double
wrapping or "self-link" in the first place, but the way this visitor handled it make it look
like a cyclic link. It should stop once it finds that the ProjectedColumnExpression has been
projected from another ProjectedColumnExpression, for the second projected column does not
belong to the projector we have in this visitor (we don't have the information of the projectors
at further levels).

The multi-level projection itself shouldn't be considered a problem for it is logical in cases
like nested derived tables. I'll check-in with a fix shortly.

> Investigate not setting ProjectedColumnExpression in TupleProjector expressions array
> -------------------------------------------------------------------------------------
>
>                 Key: PHOENIX-1854
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-1854
>             Project: Phoenix
>          Issue Type: Improvement
>            Reporter: James Taylor
>            Assignee: Maryann Xue
>            Priority: Minor
>             Fix For: 4.8.0
>
>
> In implementing PHOENIX-1826, on the visit of a ProjectedColumnExpression, we dereference
the TupleProjector expressions array and continue the visit on the expression. To prevent
a stack overflow due to infinite recursion, we detect the case when the dereferenced ProjectedColumnExpression
is the same as the expression being visited and do not continue the traversal.  See FIXME
in OrderPreservingTracker.TrackOrderPreservingExpressionVisitor:
> {code}
>         @Override
>         public Info visit(ProjectedColumnExpression node) {
>             if (projector == null) {
>                 return super.visit(node);
>             }
>             Expression expression = projector.getExpressions()[node.getPosition()];
>             // FIXME: prevents infinite recursion for union all in subquery, but
>             // should a ProjectedColumnExpression be used in this case? Wouldn't
>             // it make more sense to not create this wrapper in this case?
>             if (expression == node) {
>                 return super.visit(node);
>             }
>             return expression.accept(this);
>         }
> {code}
> It's possible that this wrapping is not necessary in the first place.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message