[ 
https://issues.apache.org/jira/browse/AVRO-1340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15571807#comment-15571807
 ] 

Dave Latham commented on AVRO-1340:
-----------------------------------

I think the 95% case is the UNKNOWN value.  I have a reader and I just don't 
want it to fall over when some new values that I don't know about start showing 
up in my enum.  Having general, writer-specified fallback logic is certainly 
more powerful, but gets much more complex for people to understand.  What about 
if you have multiple versions of old readers floating around?  Are you going to 
define multiple levels of fall back?  To take [~zi]'s example:

{code}
enum Error {
  SUCCESS,
  @deprecated READ_FAILURE,
  @deprecated ABORTED,
  FILE_NOT_FOUND ? READ_FAILURE,
  @deprecated NO_PERMISSION_TO_READ_FILE ? READ_FAILURE,
  DISK_ERROR ? READ_FAILURE,
  CANCELLED_BY_USER ? ABORTED,
  TIMED_OUT ? ABORTED
  AUTHENTICATION_ERROR ? NO_PERMISSION_TO_READ_FILE
  AUTHORIZATION_ERROR ? NO_PERMISSION_TO_READ_FILE
}
{code}

Then we need to parse it as a graph, and outlaw cycles?

I don't think it's worth the complexity.  We should start with a simple default 
or UNKNOWN value for readers who want to be able to handle unknown values, and 
see if in practice this is still a problem for people.

> 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)

Reply via email to