[
https://issues.apache.org/jira/browse/AVRO-1340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16154434#comment-16154434
]
Felix GV edited comment on AVRO-1340 at 9/5/17 9:54 PM:
--------------------------------------------------------
Hi [~cutting],
I think I may not have been clear in how I was describing it. Here is a
potential way that aliases can serve not only the use case of renaming fields,
but also the default value use case:
Let's assume that the new compatibility rule is that a schema adding a new enum
value, must provide an alias from the new value to one of the old values. This
would allow use cases such as:
V3:
{code:java}
"name":"httpResponseCode",
"symbols":["UNKNOWN", "200", "404", "500", "300"]
{code}
V5:
{code:java}
"name":"httpResponseCode",
"symbols":["UNKNOWN", "200", "404", "500", "300", "301", "302"],
"symbolAliases": {"300":["301", "302"]}
{code}
When performing the translation, a V3 reader armed with the V5 writer schema
would be capable of reading the new enum values (301, 302) as if they were
another value which they already know about (in this case, 300).
This aliasing mechanism could be considered slightly more powerful than default
values (also referred to as a fallback symbol in the above proposals) because
they could basically allow different fallbacks for different enum values. For
example:
V7:
{code:java}
"name":"httpResponseCode",
"symbols":["UNKNOWN", "200", "404", "500", "300", "301", "302", "400"],
"symbolAliases": {"300":["301", "302"], "400": ["UNKNOWN"]}
{code}
Basically, in this model, it is the responsibility of the new schema to define
how readers using the old schema will interact with data written using the new
schema.
It may be a little awkward, and too flexible for most use cases' needs, but I
think the above examples demonstrate how it can potentially serve as a "default
value" mechanism as well as a renaming mechanism.
I'm not advocating for having aliases rather than default values BTW. I am
arguing that having just one of the two mechanisms would be simpler to reason
with than having both.
was (Author: felixgv):
Hi [~cutting],
I think I may not have been clear in how I was describing it. Here is a
potential way that aliases can serve not only the use case of renaming fields,
but also the default value use case:
Let's assume that the new compatibility rule is that a schema adding a new enum
value, must provide an alias from the new value to one of the old values. This
would allow use cases such as:
V3:
{code:java}
"name":"httpResponseCode",
"symbols":["UNKNOWN", "200", "404", "500", "300"]
{code}
V5:
{code:java}
"name":"httpResponseCode",
"symbols":["UNKNOWN", "200", "404", "500", "300", "301", "302"],
"symbolAliases": {"300":["301", "302"]}
{code}
When performing the translation, a V3 reader armed with the V5 writer schema
would be capable of reading the new enum values (301, 302) as if they were
another value which they already know about (in this case, 300).
This aliasing mechanism could be considered slightly more powerful than default
values (also referred to as a fallback symbol in the above proposals) because
they could basically allow different fallbacks for different enum values. For
example:
V7:
{code:java}
"name":"httpResponseCode",
"symbols":["UNKNOWN", "200", "404", "500", "300", "301", "302"],
"symbolAliases": {"300":["301", "302"], "400": ["UNKNOWN"]}
{code}
Basically, in this model, it is the responsibility of the new schema to define
how readers using the old schema will interact with data written using the new
schema.
It may be a little awkward, and too flexible for most use cases' needs, but I
think the above examples demonstrate how it can potentially serve as a "default
value" mechanism as well as a renaming mechanism.
I'm not advocating for having aliases rather than default values BTW. I am
arguing that having just one of the two mechanisms would be simpler to reason
with than having both.
> 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)
