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

Felix GV commented on AVRO-1340:
--------------------------------

Can you please describe the compatibility rules for changing not just "symbols" 
but also for changing "symbolAliases" and "fallbackSymbol"?

Can v1 have no "fallbackSymbol", v2 define "fallbackSymbol":"SPADES" and then 
v3 define "fallbackSymbol":"HEART"?

If I were to run the compatibility checker on those schemas, would they appear 
to be compatible?

The same types of questions can be constructed for "symbolAliases"...

I think the generic fallback mechanism is a little complicated to reason about 
and may not be worth it if it's only useful for 5% of cases. Having a proper 
"default" mechanism for unknown values is definitely the biggest pain point in 
Avro. In fact, in our project, we maintain enums in code but always encode them 
as int in Avro, and we recommend every other project to do the same, otherwise 
it is code smell. But fixing typos or having fancy fallback rules doesn't 
strike me as a particularly compelling use case, and is probably not worth 
adding schema and compatibility complexity for...

BTW, why not name "fallbackSymbol" as "default", to keep it inline with regular 
Avro syntax?

> 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.4.14#64029)

Reply via email to