Zoltan Ivanfi commented on AVRO-1340:

A generic fallback mechanism would allow different fallback values for 
different enum values, while the default value mechanism allows only a single 
fallback value. I see two different questions that could justify the different 

*Generic fallback mechanism*

The question for the generic fallback mechanism is what is the use-case for 
different fallback values? I agree with the previous comment that in the Suit 
enum it wouldn't make sense the make DIAMONDS fall back to HEARTS, but I think 
this enum is not the best example. I can't imagine anyone creating this enum 
with just two of the suits and then realizing months later that the other two 
also needs to be added. I would suggest a different example:

enum Error {

For the next release it may be necessary to make the different error conditions 
more specific. Using some pseudo-syntax this would give us:

enum Error {
  @deprecated READ_FAILURE,
  @deprecated ABORTED,

This would allow old code that can only differentiate between the READ_FAILURE 
and ABORTED states to still handle new error states properly.

*Single fallback value mechanism*

The question for the single fallback value mechanism is whether it provides any 
other use-case than unknown values? I personally don't see any other use for a 
single fallback value than adding an UNKNOWN value, if you have something in 
mind, please let me know.

I ask this question because if unknown values is the only use-case, then in my 
opinion we should have an unknown value mechanism instead of a fallback 
mechanism, as implementing an unknown value mechanism using the fallback 
mechanism involves a lot of boilerplate code and is error-prone. You always 
have to add an UNKNOWN value to every enum you ever plan to extend and specify 
it as the default value. If you forgot to add an UNKNOWN value, you are out of 
luck, because even if you add it later and specify it as the fallback value, 
the UNKNOWN enum value will be literally _unknown_ to old code and we are back 
at the original problem.

> 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

Reply via email to