[
https://issues.apache.org/jira/browse/FLINK-11449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16757301#comment-16757301
]
Timo Walther commented on FLINK-11449:
--------------------------------------
Thanks for working on this [~sunjincheng121]. I went through all expressions in
{{expressionDsl.scala}} and {{ExpressionParser}} to check how the interfaces
between API and planner could look like. In the long-term vision, we should
treat built-in functions and user-defined functions the same. At the same time,
we should also keep the reworking efforts for the Blink merge low. That's why I
would let the current expression subclasses untouched and let them stay in
{{flink-table-planner}}/{{flink-table-planner-blink}}. I would suggest the
following class structure:
In {{flink-table-api-common}}, because we can even put those expression classes
into flink-table-common for FilterableTableSources in the future:
{code}
public class FunctionDefinition {
public String name;
}
public class UserDefinedFunctionDefinition extends FunctionDefinition {
// the name is ignored for now
public UserDefinedFunction f;
}
public class Expression {
abstract List<Expression> getChildren();
abstract <R> R accept(ExpressionVisitor<R> visitor);
// do we need more methods here?
}
CallExpression(FunctionDefinition, Expression*) extends Expression
SymbolExpression(TableSymbol ???) extends Expression
FieldReferenceExpression(String) extends Expression
TableReferenceExpression(String, Table) extends Expression
TypeLiteralExpression(TypeInformation) extends Expression
ValueLiteralExpression(Object, TypeInformation) or
ValueLiteralExpression(Object) extends Expression
{code}
In {{flink-table-api-java}}:
{code}
public final class FunctionDefinitions {
// implement just a basic definition (only name) for know
// we can extend this functionality in the future with type inference
logic etc.
public static final FunctionDefinition TRIM = new
FunctionDefinition("trim");
public static final FunctionDefinition CAST = new
FunctionDefinition("cast");
public static List<FunctionDefinitions> getDefinitions() {
// use reflection for all definitions similar to Calcite's
SqlStdOperatorTable
}
}
{code}
In {{flink-table-planner}}:
{code}
+ visitor pattern in the planner to translate
in Flink: to Flink's case classes
in Blink: to Blink's case classes
visit(call Call) match {
case TRIM => ....
}
{code}
What do you think?
> Uncouple the Expression class from RexNodes
> -------------------------------------------
>
> Key: FLINK-11449
> URL: https://issues.apache.org/jira/browse/FLINK-11449
> Project: Flink
> Issue Type: New Feature
> Components: Table API & SQL
> Reporter: Timo Walther
> Assignee: sunjincheng
> Priority: Major
>
> A more detailed description can be found in
> [FLIP-32|https://cwiki.apache.org/confluence/display/FLINK/FLIP-32%3A+Restructure+flink-table+for+future+contributions].
> Calcite will not be part of any API module anymore. Therefore, RexNode
> translation must happen in a different layer. This issue will require a new
> design document.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
