[
https://issues.apache.org/jira/browse/DRILL-5321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Rogers updated DRILL-5321:
-------------------------------
Affects Version/s: (was: 1.10.0)
1.11.0
Fix Version/s: (was: Future)
1.11.0
> Refactor FragmentContext for unit testing
> -----------------------------------------
>
> Key: DRILL-5321
> URL: https://issues.apache.org/jira/browse/DRILL-5321
> Project: Apache Drill
> Issue Type: Sub-task
> Components: Tools, Build & Test
> Affects Versions: 1.11.0
> Reporter: Paul Rogers
> Assignee: Paul Rogers
> Fix For: 1.11.0
>
>
> 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
(v6.3.15#6346)
