Another outstanding bit for the release in my mind is the state of the UUID logicalType. As Ryan commented here: https://issues.apache.org/jira/browse/AVRO-2021?focusedCommentId=16242524&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16242524 there is currently an implemented logical type of 'uuid', however it uses the naive toString/fromString rather than a more compact 16-byte fixed. I think we should think about whether we really need this logical type as it doesn't provide much benefit as it is. What do you think?
Related is UUID support for ReflectData, which is currently nil (we cannot even annotate @Stringable; UUID has no String constructor). Basically the only option for using UUIDs in ReflectData is the user implementing their own CustomEncoding. A long unanswered query on another Jira is here: https://issues.apache.org/jira/browse/AVRO-1497?focusedCommentId=16283656&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16283656 We could either: - Provide CustomEncoding implementation(s), such as UUIDAsStringEncoding and/or UUIDAsFixedEncoding - Add support for LogicalTypes in ReflectData definitions, through a new annotation a la @AvroLogicalType("timestamp-millis"), etc. where we can use the uuid logicalType if we decide to keep that in Taking a look at the history it seems as though LogicalTypes and CustomEncodings share some of the same intentions. It's not clear what the better option is in this case. CustomEncoding predates LogicalType by a few years, but CustomEncoding is more Java-centric. Please let me know what the thoughts are. I should have some time to work on what we decide on this week. Would like to get these items in for 1.9. -- Ivan
