Just to clarify, the UUID logical type was included in 1.8.2 (and perhaps a release prior to that?), it was just undocumented. So I think one option could be providing a conversion both to/from string and to/from 16-length fixed, similar to the way that the decimal type provides conversion to/from fixed as well as to/from bytes, which can be chosen by the user.
—Ivan > On Apr 9, 2019, at 9:02 AM, Driesprong, Fokko <[email protected]> wrote: > > Hi Ivan, > > Thanks for the input. Personally, I'm not using the UUID at all. Any > comments on it Ryan? Since it isn't introduced in any release, we could > remove it if there is a consensus if it doesn't add any value to the Avro > format. > > Apart from that, I did some testing last week on some internal projects, > and it went surprisingly well. I would like to proceed into cutting a first > RC. > > Cheers, Fokko > > Op di 2 apr. 2019 om 03:49 schreef Ivan Greene <[email protected]>: > >> 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 <[email protected]> >> 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 >>> >>
