[
https://issues.apache.org/jira/browse/PIG-161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12589374#action_12589374
]
Shravan Matthur Narayanamurthy commented on PIG-161:
----------------------------------------------------
To me the name relational operator does not make any sense at all.
http://en.wikipedia.org/wiki/Relational_operator
For lack of better terms I just named them as top level operators. But I see
your point. The same operators can be nested too. So calling them top level
does not make any sense either.
Guess we need some cleaner terminology.
Also, I wasn't planning to put Hadoop in PhysicalLayer. I was thinking of
introducing a separate Map Reduce Layer because really our code works that way.
We have a logical layer, a physical layer and then the physical plan, which is
the output of the physical layer, is converted into Map Reduce.
I guess we can leave it as is right now since package refactoring will involve
a lot of work on Alan's side as he is the only one with committer access. We
can think about it and then once we have consensus, we can refactor the code.
But point taken. Thanks!
> Rework physical plan
> --------------------
>
> Key: PIG-161
> URL: https://issues.apache.org/jira/browse/PIG-161
> Project: Pig
> Issue Type: Sub-task
> Reporter: Alan Gates
> Assignee: Alan Gates
> Attachments: arithmeticOperators.patch, incr2.patch, incr3.patch,
> incr4.patch, Phy_AbsClass.patch, pogenerate.patch, pogenerate.patch,
> pogenerate.patch
>
>
> This bug tracks work to rework all of the physical operators as described in
> http://wiki.apache.org/pig/PigTypesFunctionalSpec
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
