[
https://issues.apache.org/jira/browse/DRILL-2938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Altekruse updated DRILL-2938:
-----------------------------------
Description:
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
> 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
>
> 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)
