[
https://issues.apache.org/jira/browse/PIG-290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12614115#action_12614115
]
Santhosh Srinivasan commented on PIG-290:
-----------------------------------------
The edge ordering in the implementation is the order in which the connections
were made. This is a side effect of using a list to store the edges. While this
does not appear to be a clean solution, the scope of changing the definition of
the logical operators LOCross and LOCogroup is widespread. The changes will
affect the optimizer which has to re-wire the inputs when operators are moved
around in the graph.
For now, I would go with the proposed change. We can fix the issue as an
enhancement when we merge from types branch to trunk.
> LOCross output schema is not right
> ----------------------------------
>
> Key: PIG-290
> URL: https://issues.apache.org/jira/browse/PIG-290
> Project: Pig
> Issue Type: Bug
> Components: impl
> Affects Versions: types_branch
> Reporter: Pi Song
> Assignee: Santhosh Srinivasan
> Fix For: types_branch
>
> Attachments: insert_between.patch
>
>
> From the schema generation code:-
> {noformat}
> List<LogicalOperator> inputs = mPlan.getPredecessors(this);
> for (LogicalOperator op : inputs) {
> // Create schema here
> }
> {noformat}
> The output schema is generated based on inputs determined in the logical
> plan. However, mPlan.getPredecessors() doesn't always preserve the right
> order (A x B and B x A result in different schemas). I suggest maintaining
> mInputs variable in LOCross (as it used to be) to resolve this issue.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
