[ https://issues.apache.org/jira/browse/AVRO-1340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15571729#comment-15571729 ]
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 approaches: *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: {code} enum Error { SUCCESS, READ_FAILURE, ABORTED } {code} For the next release it may be necessary to make the different error conditions more specific. Using some pseudo-syntax this would give us: {code} enum Error { SUCCESS, @deprecated READ_FAILURE, @deprecated ABORTED, FILE_NOT_FOUND ? READ_FAILURE, PERMISSION_DENIED ? READ_FAILURE, DISK_ERROR ? READ_FAILURE, CANCELLED_BY_USER ? ABORTED, TIMED_OUT ? ABORTED } {code} 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 (v6.3.4#6332)