[
https://issues.apache.org/jira/browse/FLINK-9294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rong Rong updated FLINK-9294:
-----------------------------
Description:
Most of the UDF function signatures that includes composite types such as
*{{MAP}}*, *{{ARRAY}}*, etc would require user to override
*{{getParameterType}}* or *{{getResultType}}* method explicitly.
It should be able to resolve the composite type based on the function
signature, such as:
{code:java}
public String[] eval(Map<String, Integer> mapArg) { /* ... */ }
{code}
The function catalog search should do either of the following:
[Update]
since we have backward compatibility issue with resolving to a different type,
we will not go with the modify type option.
- -Automatically resolve that:-
-1. *{{ObjectArrayTypeInfo<BasicTypeInfo.STRING>}}* to be the result type.-
-2. *{{MapTypeInfo<BasicTypeInfo.STRING, BasicTypeInfo.INTEGER>}}* to be the
parameter type.-
- Improved function mapping to find and locate function with such signatures
[Update]
This ticket should only cover Map and Row type, and does not cover Array, since
Array is actually resolved by eval method signature correctly.
This ticket should consolidate some discrepancy between how TableFunction,
AggregateFunction and ScalarFunction resolves types. which at this moment goes
through different code path.
The rest of the optimization should go to follow up tickets in FLINK-9484
was:
Most of the UDF function signatures that includes composite types such as
*{{MAP}}*, *{{ARRAY}}*, etc would require user to override
*{{getParameterType}}* or *{{getResultType}}* method explicitly.
It should be able to resolve the composite type based on the function
signature, such as:
{code:java}
public String[] eval(Map<String, Integer> mapArg) { /* ... */ }
{code}
The function catalog search should do either of the following:
[Update] since we have backward compatibility issue with resolving to a
different type, we will not go with the modify type option.
- -Automatically resolve that:-
-1. *{{ObjectArrayTypeInfo<BasicTypeInfo.STRING>}}* to be the result type.-
-2. *{{MapTypeInfo<BasicTypeInfo.STRING, BasicTypeInfo.INTEGER>}}* to be the
parameter type.-
- Improved function mapping to find and locate function with such signatures
[Update]
This ticket should only cover Map and Row type, and does not cover Array, since
Array is actually resolved by eval method signature correctly.
This ticket should consolidate some discrepancy between how TableFunction,
AggregateFunction and ScalarFunction resolves types. which at this moment goes
through different code path.
The rest of the optimization should go to follow up tickets in FLINK-9484
> Improve type inference for UDFs with composite parameter or result type
> ------------------------------------------------------------------------
>
> Key: FLINK-9294
> URL: https://issues.apache.org/jira/browse/FLINK-9294
> Project: Flink
> Issue Type: Sub-task
> Components: Table API & SQL
> Reporter: Rong Rong
> Assignee: Rong Rong
> Priority: Major
>
> Most of the UDF function signatures that includes composite types such as
> *{{MAP}}*, *{{ARRAY}}*, etc would require user to override
> *{{getParameterType}}* or *{{getResultType}}* method explicitly.
> It should be able to resolve the composite type based on the function
> signature, such as:
> {code:java}
> public String[] eval(Map<String, Integer> mapArg) { /* ... */ }
> {code}
> The function catalog search should do either of the following:
> [Update]
> since we have backward compatibility issue with resolving to a different
> type, we will not go with the modify type option.
> - -Automatically resolve that:-
> -1. *{{ObjectArrayTypeInfo<BasicTypeInfo.STRING>}}* to be the result type.-
> -2. *{{MapTypeInfo<BasicTypeInfo.STRING, BasicTypeInfo.INTEGER>}}* to be the
> parameter type.-
> - Improved function mapping to find and locate function with such signatures
>
> [Update]
> This ticket should only cover Map and Row type, and does not cover Array,
> since Array is actually resolved by eval method signature correctly.
> This ticket should consolidate some discrepancy between how TableFunction,
> AggregateFunction and ScalarFunction resolves types. which at this moment
> goes through different code path.
> The rest of the optimization should go to follow up tickets in FLINK-9484
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
