[
https://issues.apache.org/jira/browse/AVRO-1721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14739877#comment-14739877
]
Doug Cutting commented on AVRO-1721:
------------------------------------
We distinguish between changes that break an implementation versus changes that
break binary compatibility between implementations. We (reluctantly) permit
incompatible changes to implementations in minor releases, but would require a
major release to break binary compatibility (and might never actually do this).
Logical types are optional hints to implementations and do not affect the
encoding, only the in-memory representation of some implementations. So
incompatible changes to logical type handling might be made in minor releases,
but not point (bugfix) releases.
However the case you mention, adding a UUID logical type to a schema causing a
change in the runtime type, doesn't seem like an incompatibility. An
incompatible change causes an un-altered application to break. If you alter
the schema then that's a change to the application. It would be an
incompatible change if there were already UUID logical types in use within
applications and the runtime behavior were altered to represent them
differently.
> Should LogicalTypes introduce schema (in)compatibility and canonical parsing
> form changes?
> ------------------------------------------------------------------------------------------
>
> Key: AVRO-1721
> URL: https://issues.apache.org/jira/browse/AVRO-1721
> Project: Avro
> Issue Type: Improvement
> Components: spec
> Affects Versions: 1.8.0
> Reporter: Bob Cotton
>
> During a recent spike of integrating LogcialTypes into our Avro
> wrapper we encountered the the following questions.
> 1. Is the addition/removal of a logical to a schema element a backward
> breaking change?
> 2. Should the canonical parsing form include logical type information?
> I understand that the underlying base Avro types are not changing with
> the introduction of LogicalTypes. The raw serialized data will be the
> same. However the client code dependent on the deserialization may be
> subject to breakage.
> Let me elaborate on these.
> 1. Is the addition/removal of a logical to a schema element a backward
> breaking change?
> Take for example the UUID logical type. At least in the case of
> GenericData, if I change a schema element from a string to a UUID and
> I have Converters turned on, existing client code that is expecting a
> String to be returned will now have a runtime exception when an
> instance of UUID is suddenly returned.
> From the client's perspective I've just change the underlying type of
> the element.
> 2. Should the canonical parsing form (CPF) include logical type information?
> If the answer to #1 is yes, then the CPF should also include the
> logical type information.
> We were wondering if there might be a slightly less strict form of
> schema "normalization" and fingerprinting. Currently the
> fingerprinting process is based on the CPF. It would be interesting to
> introduce the "Normal Parsing Form" (NPF) which retains all the
> optional information contained within a schema, but in a normal or
> regular way. That way a fingerprint could be determined without having
> to script possibly important information, like the LogicalType info.
> Interested in your thoughts on these questions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
