Using named keys in keyBy() for nested POJO types results in failure. The iindexes for named key fields are used inconsistently with nested POJO types. In particular, PojoTypeInfo.getFlatFields() returns the field's position after (apparently) flattening the structure but is referenced in the unflattened version of the POJO type by PojoTypeInfo.getTypeAt().
In the example below, getFlatFields() returns positions 0, 1, and 14. These positions appear correct in the flattened structure of the Data class. However, in KeySelector<X, Tuple> getSelectorForKeys(Keys<X> keys, TypeInformation<X> typeInfo, ExecutionConfig executionConfig), a call to compositeType.getTypeAt(logicalKeyPositions[i]) for the third key results PojoTypeInfo.getTypeAt() declaring it out of range, as it compares the length of the directly named fields of the object vs the length of flattened version of that type.
Consider this graph:
DataDeserialzer returns a "NativeDataFormat" object; DataMapper takes this NativeDataFormat object and extracts individual Data objects:
A Policy object is an instance of this class:
A Stats object is an instance of this class: