[jira] [Commented] (PIG-3898) Refactor PPNL for non-MR execution engine

["Prashant Kommireddi (JIRA)" <ji...@apache.org>]

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

Prashant Kommireddi commented on PIG-3898:
------------------------------------------

I'm a +1 on the first approach. It's the right thing to do in this case, in terms of method signature having a base Interface rather than an implementation (OperatorPlan vs MROperPlan). PPNL is marked evolving which tells the the compatibility can be broken between minor releases (though not desired). It's unfortunate that we need to be doing it and users need to adjust, but sooner we make the change the better IMHO.

Let's also send out a note to Pig user mailing list in case we all agree to go ahead with approach 1.

> Refactor PPNL for non-MR execution engine
> -----------------------------------------
>
>                 Key: PIG-3898
>                 URL: https://issues.apache.org/jira/browse/PIG-3898
>             Project: Pig
>          Issue Type: Task
>            Reporter: Cheolsoo Park
>            Assignee: Cheolsoo Park
>             Fix For: 0.13.0
>
>
> Currently, PPNL assumes the MR plan, and thus, it's not compatible with non-MR execution engine. To support non-MR execution engines, I propose we changed initialPlanNotification() method as follows-
> {code:title=from}
> public void initialPlanNotification(String scriptId, MROperPlan plan);
> {code}
> {code:title=to}
> public void initialPlanNotification(String scriptId, OperatorPlan<?> plan);
> {code}
> Since MROperPlan and TezOperPlan are a subclass of OperatorPlan, this method can take both plans. In addition, if we add a new execution engine in the future, it won't break the interface again as long as we build the operator plan as a subclass of OperatorPlan.
> With this approach, applications such as Ambrose / Lipstick should be able to dynamically cast OperatorPlan to a concrete subclass depending on the ExecType.
> One disadvantage is that this isn't backward compatible with Pig 0.12 and older. But it only requires minor changes, and backward compatibility will be broken one time only.
> I also considered an alternative approach, for example, adding a new PPNL for Tez. But this approach has two problems.
> # Pig registers PPNL via the Main function, and right now, only one PPNL can be registered. So having more than one PPNLs requires quite a few code changes in Main, ScriptState, and so on.
> # Multiple PPNL interfaces mean multiple PPNL implementations. This results in more (duplicate) code in applications such as Ambrose / Lipstick.



--
This message was sent by Atlassian JIRA
(v6.2#6252)