You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@calcite.apache.org by "Julian Hyde (JIRA)" <ji...@apache.org> on 2014/12/19 19:04:14 UTC

[jira] [Commented] (CALCITE-466) Move the "enumerable" adapter out of core

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

Julian Hyde commented on CALCITE-466:
-------------------------------------

I did an experimental refactoring in https://github.com/julianhyde/incubator-calcite/tree/calcite-466. I basically moved the org.apache.calcite.adapter.enumerable package and org.apache.calcite.schema.impl.{AggregateFunctionImpl, ScalarFunctionImpl, TableFunctionImpl} to a new "enumerable" maven module. I introduced EnumerableSuite, and moved EnumerableCorrelateTest.

Here are the breakages, and possible remedies:
* RelOptTableImpl depends on EnumerableTableScan
* SqlUserDefinedTableMacro depends on RexToLixTranslator
* JdbcToEnumerableConverter depends on EnumerableRelImpl and EnumerableRel
** Possible fix: Change it to JdbcToInterpreterConverter
* Nodes depends on FilterTableRule
* FilterTableRule depends on EnumerableInterpreter
** Possible fix: Add a new INTERPRETER convention, and InterpreterConverter rel, make the rule depend on InterpreterConverter not EnumerableInterpreter.
** EnumerableInterpreter would go away; there might be an interpreter to enumerable converter
* SplunkTableScan depends on EnumerableRel and EnumerableConvention
** It should use INTERPRETER convention
* ModelHandler depends on TableFunctionImpl, ScalarFunctionImpl, AggregateFunctionImpl
** Either introduce a "compiler" callback or keep TableFunctionImpl, ScalarFunctionImpl, AggregateFunctionImpl in the core module
* CalcitePreparingStmt depends on EnumerableRel and EnumerableConvention
** It should consume instead INTERPRETER convention (typically using the enumerable-to-interpreter converter)

Each of the breakages is "X in core depends on Y in enumerable". Typical remedies are to move X to enumerable, or Y back into core. But we may need something more complicated, since we have to cut somewhere.

> Move the "enumerable" adapter out of core
> -----------------------------------------
>
>                 Key: CALCITE-466
>                 URL: https://issues.apache.org/jira/browse/CALCITE-466
>             Project: Calcite
>          Issue Type: Bug
>            Reporter: Julian Hyde
>            Assignee: Julian Hyde
>
> In discussions for CALCITE-296, [~pipfiddle] suggested that we move the enumerable adapter -- that implements the core relational expressions by generating iterator-like code -- out of core.
> In that change, we changed package names. In this change, we keep the same package names, but move files into a new directory structure, and maven module, enumerable. Considerable refactoring is required. A lot of tests will have to be moved, because there is no implementation (except the interpreter). Other adapters (e.g. mongo) will continue to depend on this adapter, at least until they can be changed to use a non-code-generation interfaces, like ScannableTable and Interpreter.
> Goal is to fix before 1.0.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)