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

ASF GitHub Bot commented on DRILL-5842:
---------------------------------------

Github user paul-rogers commented on the issue:

    https://github.com/apache/drill/pull/978
  
    @sohami, pushed a commit that addresses your PR comments.
    
    Regarding the "one stop shop" comment. This PR removes the 
`OperExecContextImpl` class. That class was an earlier attempt to combine the 
three items into one. Additional experience showed that the existing operator 
context could do that task instead.
    
    This PR did not change existing operators to avoid passing around multiple 
items. Instead, it allows new code (for the batch size limitation project) to 
pass just the operator context, and use that to obtain the other two items. The 
external sort had to be changed because it used the old `OperExecContextImpl` 
for that purpose, and so the code had to be updated when `OperExecContextImpl` 
was removed.


> Refactor and simplify the fragment, operator contexts for testing
> -----------------------------------------------------------------
>
>                 Key: DRILL-5842
>                 URL: https://issues.apache.org/jira/browse/DRILL-5842
>             Project: Apache Drill
>          Issue Type: Improvement
>    Affects Versions: 1.12.0
>            Reporter: Paul Rogers
>            Assignee: Paul Rogers
>             Fix For: 1.12.0
>
>
> Drill's execution engine has a "fragment context" that provides state for a 
> fragment as a whole, and an "operator context" which provides state for a 
> single operator. Historically, these have both been concrete classes that 
> make generous references to the Drillbit context, and hence need a full Drill 
> server in order to operate.
> Drill has historically made extensive use of system-level testing: build the 
> entire server and fire queries at it to test each component. Over time, we 
> are augmenting that approach with unit tests: the ability to test each 
> operator (or parts of an operator) in isolation.
> Since each operator requires access to both the operator and fragment 
> context, the fact that the contexts depend on the overall server creates a 
> large barrier to unit testing. An earlier checkin started down the path of 
> defining the contexts as interfaces that can have different run-time and 
> test-time implementations to enable testing.
> This ticket asks to refactor those interfaces: simplifying the operator 
> context and introducing an interface for the fragment context. New code will 
> use these new interfaces, while older code continues to use the concrete 
> implementations. Over time, as operators are enhanced, they can be modified 
> to allow unit-level testing.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Reply via email to