[
https://issues.apache.org/jira/browse/AVRO-1340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15571729#comment-15571729
]
Zoltan Ivanfi edited comment on AVRO-1340 at 10/13/16 12:14 PM:
----------------------------------------------------------------
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,
NO_PERMISSION_TO_READ_FILE ? 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.
was (Author: zi):
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)
