[ 
https://issues.apache.org/jira/browse/PIG-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12585197#action_12585197
 ] 

Shravan Matthur Narayanamurthy commented on PIG-158:
----------------------------------------------------

I thought Santosh was mentioning the same approach that I used and hence said 
that what Pi suggested looks similar.

I use the same plans within operators approach on the physical side and 
everything is an operator for me as well :)

However, while implementing the physical to mapreduce translation, I have found 
the visitor pattern to be more constraining than useful. I was wondering if the 
visitor pattern is the right pattern to use for all our needs. In the worst 
case we would have to maintain much of the state the java compiler maintains 
for recursive calls. Also in many cases, the tasks that we do for each 
different operator tends to be the same.

So my point is just that we should not to get stuck with the visitor pattern. 
May be simple recursion has an elegant answer.

@Alan:
I am not very clear as to how the Walker/Visitor thingy interacts/works. 
Should f.getComp()... be replaced by w.visit()?

If you pop the walker out of the stack once you are done visiting the nested 
plan, how are you maintaining state across visitations of the nested plan?

> Rework logical plan
> -------------------
>
>                 Key: PIG-158
>                 URL: https://issues.apache.org/jira/browse/PIG-158
>             Project: Pig
>          Issue Type: Sub-task
>          Components: impl
>            Reporter: Alan Gates
>            Assignee: Alan Gates
>         Attachments: logical_operators.patch, logical_operators_rev_1.patch, 
> logical_operators_rev_2.patch, logical_operators_rev_3.patch
>
>
> Rework the logical plan in line with 
> http://wiki.apache.org/pig/PigExecutionModel

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to