Thank you Zoltan. Is your fork publicly available, could I take a look at it?
On Sat, Jun 15, 2019 at 5:30 AM Zoltan Farkas <zolyfar...@yahoo.com> wrote: > I agree with your understanding of how aliases should work, and a lot of > developers I interact with expect that aliases should work this way. > When I implemented https://issues.apache.org/jira/browse/AVRO-1752 in my > avro fork I implemented the resolution the way your describe it. > > I see no reason why this could not be implemented as part of 2.0… but I > would let others with more authority chime in. > > —Z > > > > On Jun 14, 2019, at 10:01 PM, Aaron Dixon <atdi...@gmail.com> wrote: > > I asked this question on the dev list, but didn't get a response here. (My > original question to the dev list: > https://sematext.com/opensee/m/F2svI1cI2oW1CwdmF1?subj=readers+using+writer+s+aliases+ > ) > > It also seems this question was asked before in late 2018, but dead-ended > at > https://sematext.com/opensee/m/Avro/F2svI1obxDi4WGqf1?subj=Re+Alias+with+Backward+Compatibility > > Avro aliases are typically used by *reader* schemas to rename fields. > (I.e., readers can expect "first-name" string and use an alias "firts-name" > to deal with old writer's that had it mispelled in the original writer > schema.) This is backwards compatibility (new readers can read old writers). > > However we would like to not have to update reader code to deal with new > writers (ie we want *forward* compatibility with aliases). It seems that > this should be easy: (old) readers could look at the new writer-defined > aliases and leverage them for forward compatibility while doing schema > resolution. > > Concrete example: my old schema expects "firts-name"; my new schema fixes > this by introducing "first-name" with the "firts-name" as an alias. Instead > of being obligated to update my old reader(s), couldn't the schema > resolution logic notice this alias and *invert* the aliasing as it reads > the data to give the old reader the field it expects? > > Is there a fundamental reason that this isn't part of the avro java impl, > or spec documentation? Not having to coordinate updates to readers during > schema evolution (field renames) would be a huge win imo. > > >
