Mailing-List: contact dev-help@flink.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@flink.apache.org
MIME-Version: 1.0
Sender: ewenstephan@gmail.com
In-Reply-To: <56405A16.30004@apache.org>
References: 
 <CA+faj9xdkEyGVJ5fa=PiyMa3fFyVkUtGBSGsk+kqZVVLmXbqsw@mail.gmail.com>
	<563FCC3A.2060208@apache.org>
	<563FD076.40003@apache.org>
	<83AE6276-D61F-4C22-BC58-A80DFB0D3A32@apache.org>
	<56405A16.30004@apache.org>
Date: Mon, 9 Nov 2015 10:04:56 +0100
Message-ID: 
 <CANC1h_sWob-4MB_0ndbs33RJ5RX+bEdCe3U9sajpAMbH6yezgQ@mail.gmail.com>
Subject: Re: Function input type validation
From: Stephan Ewen <sewen@apache.org>
To: "dev@flink.apache.org" <dev@flink.apache.org>
Content-Type: multipart/alternative; boundary=001a114a7b961dbcd3052417e35f

--001a114a7b961dbcd3052417e35f
Content-Type: text/plain; charset=UTF-8

I think this originally comes from the fact that we need to match the input
TypeInfo against the generic signature, for example to figure out what "T"
means in a MapFunction<Tuple2<T, Long>, T>.
That is the reason why Flink can support generic functions even though
there is type erasure at runtime.

Much nice than nullable types is to use Option[Type] for a field that may
be null. In Scala, the OptionTypeInfo adds a null/not-null byte, which is
probably what your custom nullable type also does. By adding this for Java
(with Java 8 options, or a custom option type) would solve that issue as
well. It would also let us retain the benefit that non-nullable fields are
efficiently serialized.


On Mon, Nov 9, 2015 at 9:32 AM, Chesnay Schepler <chesnay@apache.org> wrote:

> On 09.11.2015 08:49, Aljoscha Krettek wrote:
>
>> In the case of the TupleTypeInfo subclass it only works because the
>> equals method of TypleTypeInfo is used, IMHO.
>>
> I've overridden the equals method to check specifically for my
> implementation and not TupleTypeInfo, implemented a different serializer
> (and verified that it is used), and it still works.
>

--001a114a7b961dbcd3052417e35f--