Somehow only now after I sent this last message did I realize the conversion can already be controlled by adding the LogicalType to ReflectData as in TestReflectLogicalTypes.java :) So never mind on that second part.
However it's worth making a consideration about whether we are interested in revising the UUID logicalType to be 16-byte fixed rather than a 36-byte string before it is documented in this release. -- Ivan On Mon, Apr 1, 2019 at 8:30 PM Ivan Greene <igre...@fanthreesixty.com> wrote: > 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 >
