[
https://issues.apache.org/jira/browse/AVRO-3374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17541473#comment-17541473
]
Ryan Skraba commented on AVRO-3374:
-----------------------------------
Hello!
bq. Should we change the spec and allow primitive names if defined in a
namespace? Or stick to the spec and disallow primitive names in any namespace?
Hmmmm [python is also
lenient|https://github.com/apache/avro/pull/1533/files#diff-d5bd2c903fbc9d00b21cd566f5af8da89bc757ecefbf6df2a3006b84492ae124R123-R134].
This predates the change with AVRO-3370.
The implication of changing the spec is that a record called *{{ns.int}}* can
_never_ be referred to without the namespace. It can't, for example, drop the
namespace (which it could if it were named *{{ns.MyRecord}}*. I'm trying to
decide whether this is a breaking change or not, but it might be OK.
An SDK that *used* to fail on an invalid schema (because {{"their names may not
be defined in any namespace"}}) would suddenly succeed when it encountered the
schema in the JIRA, once this change was made. So it seems to me that it is
backwards compatible, but not necessarily forwards compatible -- that SDK can
start using and generating schemas that older versions won't consider valid.
What do you think?
> [Java] Fully qualified type reference "ns.int" loses namespace.
> ---------------------------------------------------------------
>
> Key: AVRO-3374
> URL: https://issues.apache.org/jira/browse/AVRO-3374
> Project: Apache Avro
> Issue Type: Bug
> Components: java
> Affects Versions: 1.11.0
> Reporter: Ryan Skraba
> Assignee: Christophe Le Saec
> Priority: Minor
> Labels: pull-requests-available
> Attachments: AVRO-3374.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> While brainstorming for AVRO-3370, I came across this special case where a
> type-reference could be considered ambiguous if the SDK is not careful when
> simplifying inherited namespaces:
> {code:json}
> {
> "type" : "record",
> "name" : "ns.int",
> "fields" : [
> {"name" : "value", "type" : "int"},
> {"name" : "next", "type" : [ "null", "ns.int" ]}
> ]
> }
> {code}
> In Java, if this code is parsed, it works as expected (as a linked list).
> If the schema is turned to a String using toString(), the namespace is
> dropped off the last {*}{{ns.int}}{*}, turning it into the primitive. That
> string can still be parsed into a Schema, but the "round-trip" modifies the
> schema in an incompatible way.
> That namespace shouldn't be dropped when producing the JSON string
> representing the Schema in Java.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
