I am wondering if it is necessary to add this extra distinction and complexity in the code.
One simple way to get around this would be simply require that user requested sorts specify all atomic fields directly. Wouldn't that be a fair restriction? I am saying this because I am seeing the API classes getting increasingly more complex and would really like to keep the newly introduced API concepts to a minimum - otherwise, the API will soon become unmaintainable. On Tue, Apr 7, 2015 at 10:01 AM, Fabian Hueske <fhue...@gmail.com> wrote: > Regular keys differ from sort keys in that they can be (somehow) sorted, > but their order is not necessarily "intuitive". So regular keys are > sufficient for sort-based grouping, but not for explicit sorting > (groupSort, partitionSort, outputSort). > > Right now, this difference is only relevant for POJOs. Since the order of > POJO fields is not (well) defined and they are ordered based on all their > fields, the resulting order is not well defined either. > We can add support for sorting POJOs if these implement Comparable or > somehow define the order of their fields (as proposed in FLINK-1665) > > 2015-04-06 14:34 GMT+02:00 Stephan Ewen <se...@apache.org>: > > > I as that a recent commit introduced the notion of sort key types, which > > have a well defined order. > > > > What is the difference to a regular key? Regular keys are also sortable, > so > > why the distinction? > > >
