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 <igre...@fanthreesixty.com>: > 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 > > >
