[
https://issues.apache.org/jira/browse/FLINK-11449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16757523#comment-16757523
]
sunjincheng edited comment on FLINK-11449 at 1/31/19 5:13 PM:
--------------------------------------------------------------
Hi, [~twalthr] Thank you for your reply, I feel that the proposal is very
meaningful to me。
Here have several places to confirm:
1. Why should FunctionDefinitions be placed in flink-table-api-java, can it be
put into flink-table-api-common?
2. All the Expression class should using in java, and expressionDsl also keep
using in scala,right?
3. The visitor which in flink-table-planner also defined in scala,right?
4. Why we should defined CAST as a function call? In my opinion, only the
funciton defined in the FunctionCatalog is defined as a funcitoncall. And
others can be defined as other Expression types? Similar to the following
definition in my prototype：
{code:java}
case class Call(functionName: String, args: Seq[Expression]) extends Expression
{
override def children: Seq[Expression] = args
}
case class Cast(child: Expression, resultType: TypeInformation[_]) extends
UnaryExpression{code}
I suggest that is it possible to divide unified built-in functions and UDFs
into multiple commits? In this JIRA we first remove the existing Expresion to
eliminate the dependency on RexNodes, is that makes sense to you?
was (Author: sunjincheng121):
Thank you for your reply, I feel that the proposal is very meaningful to me。
Here have several places to confirm:
1. Why should FunctionDefinitions be placed in flink-table-api-java, can it be
put into flink-table-api-common?
2. All the Expression class should using in java, and expressionDsl also keep
using in scala,right?
3. The visitor which in flink-table-planner also defined in scala,right?
4. Why we should defined CAST as a function call? In my opinion, only the
funciton defined in the FunctionCatalog is defined as a funcitoncall. And
others can be defined as other Expression types? Similar to the following
definition in my prototype：
{code:java}
case class Call(functionName: String, args: Seq[Expression]) extends Expression
{
override def children: Seq[Expression] = args
}
case class Cast(child: Expression, resultType: TypeInformation[_]) extends
UnaryExpression{code}
I suggest that is it possible to divide unified built-in functions and UDFs
into multiple commits? In this JIRA we first remove the existing Expresion to
eliminate the dependency on RexNodes, is that makes sense to you?
> 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)
