[
https://issues.apache.org/jira/browse/AVRO-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17103927#comment-17103927
]
Felix GV edited comment on AVRO-1329 at 5/10/20, 7:28 PM:
----------------------------------------------------------
Hindsight being 20/20, having syntactic coherence between record fields and
enum metadata does sound appealing. However, if an incompatible schema spec
change is under consideration, then making field definition in a map-style
rather than an array-style fashion is theoretically also on the table...
Personally, I think (or rather, hope) that this ship has sailed. In my opinion,
having a 2.0 version at all would be a monumental failure. The one thing that a
serialization spec ought to do is maintain compatibility as religiously as
possible. I would argue that any fully-incompatible changes (i.e. not even
backwards compatible) should be a whole new project/fork, rather than parading
as a 2.0 version of a project that intrinsically should never have a major
version bump. We can call it Captain Avro or whatever.
So essentially, my point is that there are 2 paths:
1) We consider backwards incompatible changes unacceptable, which means the
symbols array will remain forever no matter what, and we need to make the best
of the hand we’ve been dealt in terms of defining symbol metadata.
2) We consider incompatible changes acceptable, in which case, changes can be
defined in any part of the spec (i.e. record field definition is also eligible
for a facelift, not just enum definition).
Personally, I prefer working under model (1), but I would be curious to hear
the rest of the community’s opinion. Also, any plan we cook up should take into
account not just the ACSC spec but also the IDL one.
was (Author: felixgv):
Hindsight being 20/20, having syntactic coherence between record fields and
enum metadata does sound appealing. However, if an incompatible schema spec
change is under consideration, then making field definition in a map-style
rather than an array-style is theoretically also on the table...
Personally, I think (or rather, hope) that this ship has sailed. In my opinion,
having a 2.0 version at all would be a monumental failure. The one thing that a
serialization spec ought to do is maintain compatibility as religiously as
possible. I would argue that any fully-incompatible changes (i.e. not even
backwards compatible) should be a whole new project/fork, rather than parading
as a 2.0 version of a project that intrinsically should never have a major
version bump. We can call it Captain Avro or whatever.
So essentially, my point is that there are 2 paths:
1) We consider backwards incompatible changes unacceptable, which means the
symbols array will remain forever no matter what, and we need to make the best
of the hand we’ve been dealt in terms of defining symbol metadata.
2) We consider incompatible changes acceptable, in which case, changes can be
defined in any part of the spec (i.e. record field definition is also eligible
for a facelift, not just enum definition).
Personally, I prefer working under model (1), but I would be curious to hear
the rest of the community’s opinion. Also, any plan we cook up should take into
account not just the ACSC spec but also the IDL one.
> Get per-symbol doc for enums
> ----------------------------
>
> Key: AVRO-1329
> URL: https://issues.apache.org/jira/browse/AVRO-1329
> Project: Apache Avro
> Issue Type: Improvement
> Components: doc
> Affects Versions: 1.7.4
> Reporter: Felix GV
> Priority: Minor
>
> It would be nice to have the ability to add documentation for each symbol of
> an enum.
> Doug Cutting, quoted from the mailing list:
> Documentation per enum symbol is not currently supported, but would not be
> difficult to add. Please file an issue in Jira if you'd like to see this. For
> compatibility, in Json, this would probably appear as a parallel array of
> documentation strings, e.g., something like:
> ("name": "Foo", "type":"enum", "doc":"an enum", "symbols":["X","Y"],
> "symbols-doc":["X is X", "Y is Y"]}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
