[
https://issues.apache.org/jira/browse/AVRO-3946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17819890#comment-17819890
]
Thiruvalluvan M. G. commented on AVRO-3946:
-------------------------------------------
Interesting. We have two options:
# Fix the specification and disallow single-element unions, just like Haskell
disallows single-element tuples, for example. Or,
# As you suggest, continue to allow single-element union and treat it
equivalent to the standalone element type.
While (1) will be a breaking change, (2) will promote multiple representations
of the schema, which is not desirable. But then, we already have multiple
representations: {{{{}"name": myField", "type": "long"{}}}} and {{{{}"name":
myField", "type": {"type": "long"{}}}}}. So, (2) does not introduce any new
issue.
+1 for your proposal.
> Support single-element unions for Java code generation
> ------------------------------------------------------
>
> Key: AVRO-3946
> URL: https://issues.apache.org/jira/browse/AVRO-3946
> Project: Apache Avro
> Issue Type: Improvement
> Components: java, tools
> Affects Versions: 1.11.3
> Environment: [Avro
> specification|https://avro.apache.org/docs/1.11.1/specification/#unions]
> Reporter: M. Justin
> Priority: Minor
>
> I am writing code to integrate with existing Avro-based data created by
> someone else. Their schema currently has one-element unions for their types,
> rather than just the specific types. For example:
> {code:json}
> {
> "type": "record",
> "name": "Issue",
> "namespace": "invalid.example",
> "fields": [
> {
> "name": "myField",
> "type": ["long"]
> }
> ]
> }
> {code}
> instead of:
> {code:json}
> {
> "type": "record",
> "name": "Issue",
> "namespace": "invalid.example",
> "fields": [
> {
> "name": "myField",
> "type": "long"
> }
> ]
> }
> {code}
> While this isn't idiomatic, looking at the [Avro
> Specification|https://avro.apache.org/docs/1.11.1/specification/#unions], it
> does appear to be valid. It should also be logically equivalent to the
> non-union version of this.
> The Java code generator, however, generates this field as an {{Object}}, not
> as a {{long}} like it would with the non-union type (or the {{Long}} if it
> were the {{["null", "long"]}} or {{["long", "null"]}} union).
> {code}
> java -jar avro-tools-1.11.3.jar compile schema issue.avsc .
> {code}
> produces
> {code:java}
> private java.lang.Object myField;
> {code}
> instead of
> {code:java}
> private long myField;
> {code}
> For my case, I'm going to work with the other project's developers to change
> their schema type to be the primitive type.
> However, I'm raising this issue in case you want to improve the handling of
> this case to have a single-element union generate the same code as it would
> if just as if it were instead just that single element. i.e. {{\{"name":
> myField", "type": ["long"]\}}} would generate the same code as {{\{"name":
> myField", "type": "long"\}}} currently does, which is as a {{long}} value in
> the Java code.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
