[
https://issues.apache.org/jira/browse/AVRO-1340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16326252#comment-16326252
]
Adam Bellemare commented on AVRO-1340:
--------------------------------------
I agree with Dave. I see that this ticket has been open for several years and
no one has chimed in requiring aliasing of enum values.
If a producer needs to split out an enum value into more granular enum values
without aliasing, the simplest solution would be to keep the old enum and
create a new, more granular enum. Set both of them accordingly (ie:
HttpResponseCode: 300, NewHttpResponseCode [one of 300,301,302] ) and have the
downstream consumers migrate in their own time. Though it is verbose, it is a
contractually safe redefinition of the data contract as old consumers are not
affected by the changes.
Aliasing only partially solves the issue. The example that Zoltan gave above
about multiple levels of fallback would still need to be addressed ([~zi] added
a comment - 13/Oct/16 12:08 ), as over time you would end up with multiple
evolutions of enum values aliased to other values. Maintaining it would become
very difficult as you would need to test that every new alias added doesn't
alter the resolution of previous aliases. It would be easy to introduce a
semantically-correct-but-logically-incorrect change to the aliases that
invalidate the original data contract terms.
At this point, the schema creator user would probably just give up, define a
new enum with the current values and leave the complex nesting of aliasing
behind in the old enum. This is functionally equivalent to simply just defining
a new enum for any non-additive change (ie: breaking 300 into 300, 301, 302).
Aliasing only seems to work for simple use-cases and seems quite attractive for
that, but it opens up a large can of worms and doesn't really add any value
that isn't already available in Avro.
Can we move forward with just the simple fallback value?
> use default to allow old readers to specify default enum value when
> encountering new enum symbols
> -------------------------------------------------------------------------------------------------
>
> Key: AVRO-1340
> URL: https://issues.apache.org/jira/browse/AVRO-1340
> Project: Avro
> Issue Type: Improvement
> Components: spec
> Environment: N/A
> Reporter: Jim Donofrio
> Priority: Minor
>
> The schema resolution page says:
> > if both are enums:
> > if the writer's symbol is not present in the reader's enum, then an
> error is signalled.
> This makes it difficult to use enum's because you can never add a enum value
> and keep old reader's compatible. Why not use the default option to refer to
> one of enum values so that when a old reader encounters a enum ordinal it
> does not recognize, it can default to the optional schema provided one. If
> the old schema does not provide a default then the older reader can continue
> to fail as it does today.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
