flink-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rong Rong (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FLINK-8863) Add user-defined function support in SQL Client
Date Sat, 10 Mar 2018 02:05:00 GMT

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

Rong Rong commented on FLINK-8863:

Thanks [~xccui] for the quick reply. I am assuming users would have to provide the JAR files
when launch the SQL client. 

one question I have is if there are multiple version of the same class was found, or multiple
function signature list were found in several different JARs. This can clearly be avoided
if we only limit one UDF JAR file to search functions from.

Another question is related to our use case in FLINK-7373, where we have dynamic UDF / JAR
file declaration in SQL itself, so I was wondering if there can be a optional JAR file field
to specify which JAR file function should be loading from. But, this use case could also be
categorized as "Functions that are implemented in SQL" as per [~twalthr]'s description of
the JIRA. What do you think?

> Add user-defined function support in SQL Client
> -----------------------------------------------
>                 Key: FLINK-8863
>                 URL: https://issues.apache.org/jira/browse/FLINK-8863
>             Project: Flink
>          Issue Type: Sub-task
>          Components: Table API &amp; SQL
>            Reporter: Timo Walther
>            Assignee: Xingcan Cui
>            Priority: Major
> This issue is a subtask of part two "Full Embedded SQL Client" of the implementation
plan mentioned inĀ [FLIP-24|https://cwiki.apache.org/confluence/display/FLINK/FLIP-24+-+SQL+Client].
> It should be possible to declare user-defined functions in the SQL client. For now, we
limit the registration to classes that implement {{ScalarFunction}}, {{TableFunction}}, {{AggregateFunction}}.
Functions that are implemented in SQL are not part of this issue.
> I would suggest to introduce a {{functions}} top-level property. The declaration could
look similar to:
> {code}
> functions:
>   - name: testFunction
>     from: class                                   <-- optional, default: class
>     class: org.my.MyScalarFunction
>     constructor:                                  <-- optional, needed for certain
types of functions
>       - 42.0
>       - class: org.my.Class                  <-- possibility to create objects via
>         constructor: 
>           - 1
>           - true
>           - false
>           - "whatever"
>           - type: INT
>             value: 1
> {code}

This message was sent by Atlassian JIRA

View raw message