[
https://issues.apache.org/jira/browse/AVRO-3946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
M. Justin updated AVRO-3946:
----------------------------
Description:
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"}} union).
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.
was:
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"}} union).
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.
> 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"}} union).
> 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)
