[
https://issues.apache.org/jira/browse/CALCITE-3629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17015640#comment-17015640
]
Rui Wang edited comment on CALCITE-3629 at 1/15/20 5:51 AM:
------------------------------------------------------------
Fixed in
[b80bb1c|https://github.com/apache/calcite/commit/b80bb1cbceb11ed31b73e419916b5cc98610503e].
Sorry [~zabetak] I wasn't clear enough on this JIRA. This JIRA came from
supporting TUMBLE as a table-valued function in which Danny wanted to implement
an interface for table-valued function implementor. I don't know what is the
better practice for this scenario: when working on a Jira, some new requirement
appear but the old jira has been having too many context. Should I create a
separate Jira for that new requirement or just reuse the old jira for context?
I chose to create a Jira to make each change more clear but maybe the best way
is to reuse the old Jira.
was (Author: amaliujia):
Fixed in
[b80bb1c|https://github.com/apache/calcite/commit/b80bb1cbceb11ed31b73e419916b5cc98610503e].
Sorry [~zabetak] I wasn't clear enough on this JIRA. This JIRA came from
supporting TUMBLE as a table-valued function in which Danny wanted to implement
an interface for table-valued function implementor. I don't know what is the
better practice for this scenario: when working on a Jira, some new requirement
appear. Should I create a separate Jira for that new requirement or just reuse
the old jira for context? I chose to create a Jira but maybe the best way is to
reuse the old Jira.
> Table-valued function implementor interface
> -------------------------------------------
>
> Key: CALCITE-3629
> URL: https://issues.apache.org/jira/browse/CALCITE-3629
> Project: Calcite
> Issue Type: Sub-task
> Reporter: Rui Wang
> Assignee: Rui Wang
> Priority: Major
> Fix For: 1.22.0
>
>
> The current implementation of TUMBLE is the following:
> {code:java}
> if (isTumble()) {
> // create expressions and blockstatement
> } else {
> // other table function scan enumerable implementation.
> }
> {code}
> This style is less extensible. We will add more builtin table-valued function
> implementation and we shouldn't add more if-else with complicated
> implementation.
> A better practice is in RexImpTable, each operator register its implementor,
> and then the code will be becomes:
> {code:java}
> if (implementor defined) {
> return implementor.implement(...)
> } else {
> // default table function scan enumerable implementation for those that does
> not have implementor.
> }
> {code}
> The current implementor[1] or [2] is not enough for table-valued function as
> table-valued function need both inputPhysType and outPhysType, and potential
> other params to implement itself.
> Another condition is we might need more table-valued function implementations
> to abstract a common interface.
> [1]:
> https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/adapter/enumerable/CallImplementor.java#L38
> [2]:
> https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/adapter/enumerable/NotNullImplementor.java
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
