+1 I also think it's the cleanest solution for now. The table API still works, just without support for null values.
On Thu, 18 Jun 2015 at 10:08 Maximilian Michels <m...@apache.org> wrote: > I also vote for reverting the Table API changes. > > On Wed, Jun 17, 2015 at 6:16 PM, Ufuk Celebi <u...@apache.org> wrote: > > > > > On 17 Jun 2015, at 18:05, Aljoscha Krettek <aljos...@apache.org> wrote: > > > > > -1 > > > > > > There is a bug in the newly introduced Null-Value support in > > RowSerializer: > > > The serializer was changed to write booleans that signify if a field is > > > null. For comparison this still uses the TupleComparatorBase (via > > > CaseClassComparator) which is not aware of these changes. > > > > > > The reason why no Unit-Test found this problem is that it only occurs > if > > > very long keys are used that exceed the normalised-key length. Only > then > > do > > > we actually have to compare the binary data. > > > > > > I see three options: > > > - Revert the relevant Table API changes > > > - Create a new RowComparator that does not derive from > > CaseClassComparator > > > but basically copies almost all the code > > > - Add support for null-values in Tuples and Case classes as well, > thereby > > > bringing all composite types in sync regarding null-values. > > > > I vote vor option 1 for now. > > >
