[
https://issues.apache.org/jira/browse/DRILL-2938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Westin updated DRILL-2938:
--------------------------------
Component/s: (was: Execution - Flow)
Execution - Relational Operators
> 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 - Relational Operators
> Reporter: Jason Altekruse
> Assignee: Chris Westin
> Fix For: Future
>
>
> 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)
