drill-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Rogers (JIRA)" <j...@apache.org>
Subject [jira] [Created] (DRILL-5321) Refactor FragmentContext for unit testing
Date Tue, 07 Mar 2017 17:38:38 GMT
Paul Rogers created DRILL-5321:

             Summary: Refactor FragmentContext for unit testing
                 Key: DRILL-5321
                 URL: https://issues.apache.org/jira/browse/DRILL-5321
             Project: Apache Drill
          Issue Type: Sub-task
    Affects Versions: 1.10.0
            Reporter: Paul Rogers
            Assignee: Paul Rogers
             Fix For: Future

Each operator has visibility to the {{FragmentContext}} class. {{FragmentContext}} provides
access to all of Drill internals: the Drillbit context, the network interfaces, RPC messages
and so on.

Further, all the code generation mechanisms require a {{FragmentContext}} object.

This structure creates a large barrier to unit testing. To test, say, a particular bit of
generated code, we must have the entire Drillbit running so we can obtain a {{FragmentContext}}.
Clearly, this is less than ideal.

Upon inspection, it turns out that the {{FragmentContext}} is mostly needed, by many operators,
to generate code. Of the many methods in {{FragmentContext}}, code generation uses only six.

The solution is to create a new super-interface, {{CodeGenContext}}, which holds those six
methods. The {{CodeGenContext}} can be easily re-implemented for unit testing.

Then, modify all the code-generation classes that currently take {{FragmentContext}} to take
{{CodeGenContext}} instead.

Since {{FragmentContext}} derives from {{CodeGenContext}}, existing operator code "just works."

This message was sent by Atlassian JIRA

View raw message