You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@flink.apache.org by Arujit Pradhan <ar...@gojek.com> on 2022/01/03 10:13:03 UTC

Provide DataTypeHint for ScalarUDF where the return type is Object[]

Hey team,

We are migrating our Flink codes from Flink-1.9 to Flink-1.14 and as a part
of this, we are updating a bunch of UDFs. Wanted to understand, how to
provide *data type hints for the UDFs which return Object[]*.

For example, if the return type is simply Object something like this works.

*@DataTypeHint(inputGroup = InputGroup.ANY)*

But could not find any examples on how to add type hints in case of an eval
function returning Object[]. If we explicitly, return something like
List<Object> instead of providing type hints works, but this might cause
issues downstream since lots of running jobs currently use in-built UDFs
like `*Cardinality*` on the result of the UDFs which fails if the return
type is List<Object>.

Thanks in advance.
//arujit

Re: Provide DataTypeHint for ScalarUDF where the return type is Object[]

Posted by Francesco Guardiani <fr...@ververica.com>.
Hi,

Can you provide a reproducer? Sounds like a bug, but I might be wrong.

I wonder why you need List<Object>, can't you infer the type?

In any case, You can workaround this issue overriding the method
UserDefinedFunction#getTypeInference to return a custom TypeInference,
which you can build with your own output TypeStrategy.

FG

On Mon, Jan 3, 2022 at 11:13 AM Arujit Pradhan <ar...@gojek.com>
wrote:

> Hey team,
>
> We are migrating our Flink codes from Flink-1.9 to Flink-1.14 and as a
> part of this, we are updating a bunch of UDFs. Wanted to understand, how to
> provide *data type hints for the UDFs which return Object[]*.
>
> For example, if the return type is simply Object something like this works.
>
> *@DataTypeHint(inputGroup = InputGroup.ANY)*
>
> But could not find any examples on how to add type hints in case of an
> eval function returning Object[]. If we explicitly, return something like
> List<Object> instead of providing type hints works, but this might cause
> issues downstream since lots of running jobs currently use in-built UDFs
> like `*Cardinality*` on the result of the UDFs which fails if the return
> type is List<Object>.
>
> Thanks in advance.
> //arujit
>
>