[ 
https://issues.apache.org/jira/browse/DRILL-2938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chris Westin updated DRILL-2938:
--------------------------------
    Fix Version/s: 1.2.0

> Refactor physical operators to move code out of switch statement on the 
> incoming ITER_OUTCOME value
> ---------------------------------------------------------------------------------------------------
>
>                 Key: DRILL-2938
>                 URL: https://issues.apache.org/jira/browse/DRILL-2938
>             Project: Apache Drill
>          Issue Type: Improvement
>          Components: Execution - Flow
>            Reporter: Jason Altekruse
>            Assignee: Chris Westin
>             Fix For: 1.2.0
>
>
> Currently the operators in Drill have a lot of code inside of redundant 
> switch statements on the ITER_OUTCOME of the incoming batch. This makes 
> sharing code between operators difficult and has allowed many inconsistencies 
> to crop up between operators. This has been compounded by the boilerplate 
> needed to "fill-out" on operator, which has often been copied from an 
> existing one. Defining a physical operator should be a matter of implementing 
> a straightforward interface. Useful abstract classes should be the only 
> constructs that consume the enum of ITER_OUTCOME directly, they should call 
> into methods declared on the RecordBatch interface that will correspond to 
> the operators response to a particular incoming ITER_OUTCOME.
> Another added benefit of this refactoring would allow for easier code reuse 
> between subclassed operators, they could always make a clean call to the 
> superclass method of the same name to inherit part of the behavior and extend 
> it.
> Brief proposed interface additions for RecordBatch:
> * one method for each of the ITER_OUTCOME states
>   ** possible names - probably need something better:
>      *** handle<OUTCOME_NAME>
>         **** handleOk, handleOkNewSchema, handleStop
>      *** process<OUTCOME_NAME>
>         **** processOk (this would be confusing), processOkNewSchema
>        



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

Reply via email to