flink-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Greg Hogan (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FLINK-6114) Type checking fails with generics, even when concrete type of field is not needed
Date Mon, 20 Mar 2017 12:47:41 GMT

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

Greg Hogan commented on FLINK-6114:

[~lukehutch] Flink most certainly allows {{groupBy}}s and {{join}}s on generic fields, for
example any of the Gelly algorithms in {{org.apache.flink.graph.library}}.

The Flink type system must deduce the type of all fields in order to create the serializer.
Types are defined on sources then tracked through each operation. If a type cannot be deduced
from inputs and outputs then it must be explicitly defined. We can look at this if you are
able to post more code.

> Type checking fails with generics, even when concrete type of field is not needed
> ---------------------------------------------------------------------------------
>                 Key: FLINK-6114
>                 URL: https://issues.apache.org/jira/browse/FLINK-6114
>             Project: Flink
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.2.0
>            Reporter: Luke Hutchison
> The Flink type checker does not allow generic types to be used in any field of a tuple
when a join is being executed, even if the generic is not in a field that is involved in the
> I have a type Tuple3<String, K, Float>, which contains a generic type parameter
K. I am joining using .where(0).equalTo(0). The type of field 0 is well-defined as String.
However, this gives me the following error:
> {noformat}
> Exception in thread "main" org.apache.flink.api.common.functions.InvalidTypesException:
Type of TypeVariable 'K' in 'public static org.apache.flink.api.java.DataSet mypkg.MyClass.method(params)'
could not be determined. This is most likely a type erasure problem. The type extraction currently
supports types with generic variables only in cases where all variables in the return type
can be deduced from the input type(s).
> 	at org.apache.flink.api.java.typeutils.TypeExtractor.createSubTypesInfo(TypeExtractor.java:989)
> {noformat}
> The code compiles fine, however -- the static type system is able to correctly resolve
the types in the surrounding code.
> Really only the fields that are affected by joins (or groupBy, aggregation etc.) should
be checked for concrete types in this way.

This message was sent by Atlassian JIRA

View raw message