+1 for reverting. On Thu, Jun 18, 2015 at 10:11 AM Aljoscha Krettek <aljos...@apache.org> wrote:
> +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. > > > > > >
