flink-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FLINK-7959) Split CodeGenerator into CodeGeneratorContext and ExprCodeGenerator
Date Fri, 24 Nov 2017 09:36:01 GMT

    [ https://issues.apache.org/jira/browse/FLINK-7959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16265076#comment-16265076

ASF GitHub Bot commented on FLINK-7959:

Github user twalthr commented on a diff in the pull request:

    --- Diff: flink-libraries/flink-table/src/main/scala/org/apache/flink/table/api/TableEnvironment.scala
    @@ -1002,11 +999,13 @@ abstract class TableEnvironment(val config: TableConfig) {
              |return ${conversion.resultTerm};
    -    val generated = generator.generateFunction(
    +    val generated = FunctionCodeGenerator.generateFunction(
    +      ctx,
           classOf[MapFunction[Row, OUT]],
    -      requestedTypeInfo)
    +      requestedTypeInfo,
    +      inputTypeInfo)
    --- End diff --
    If both function code generator and expression code generator need information about the
inputs, wouldn't it make sense to bind the inputs to the code generator context? Instead of
defining the same inputs twice.

> Split CodeGenerator into CodeGeneratorContext and ExprCodeGenerator
> -------------------------------------------------------------------
>                 Key: FLINK-7959
>                 URL: https://issues.apache.org/jira/browse/FLINK-7959
>             Project: Flink
>          Issue Type: Improvement
>          Components: Table API & SQL
>            Reporter: Kurt Young
>            Assignee: Kurt Young
> Right now {{CodeGenerator}} actually acts two roles, one is responsible for generating
codes from RexNode, and the other one is keeping lots of reusable statements. It makes more
sense to split these logic into two dedicated classes. 
> The new {{CodeGeneratorContext}} will keep all the reusable statements, while the new
{{ExprCodeGenerator}} will only do generating codes from RexNode.
> And for classes like {{AggregationCodeGenerator}} or {{FunctionCodeGenerator}}, I think
the should not be the subclasses of the {{CodeGenerator}}, but should all as standalone classes.
They can create {{ExprCodeGenerator}} when they need to generating codes from RexNode, and
they can also generating codes by themselves. The {{CodeGeneratorContext}} can be passed around
to collect all reusable statements, and list them in the final generated class.

This message was sent by Atlassian JIRA

View raw message