[
https://issues.apache.org/jira/browse/AVRO-2400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16849928#comment-16849928
]
Jacob Tolar commented on AVRO-2400:
-----------------------------------
{quote}Yes, good catch, lines 97 and 98 of SchemaCompatibility also need to be
updated to use getName vs getFullName.
{quote}
I can certainly make this change, but I think we should at least consider the
possibility that the pre-1.9 java resolver's behavior was 'wrong'.
SchemaCompatibility thinks it's wrong; what about the other language
implementations?. Was the behavior in 1.7.x and 1.8.x a regression from
previous versions? (1.8.x is at least consistent with 1.5.3; I haven't checked
any further back).
On the other hand, I think it's fair assume that Java is the most popularly
used implementation, and that the resolving decoder is used significantly more
than something like {{SchemaCompatibility}}. So you could make a strong
argument for keeping 1.8.2's interpretation of the specification going forward.
(This is essentially the approach we're considering here).
To be more succinct: we should be thoughtful/careful about changing the spec.
—
As an aside, it seems like the test cases in SchemaCompatibility or
SchemaValidation should be runnable across all the language implementations.
"Writer schema X should be readable by reader schema Y" shouldn't be
Java-specific and maintaining a list of regression tests could help ensure all
implementations interpret the spec in the same way.
> Avro 1.9.0 can't resolve schemas that can be resolved in 1.8.2
> --------------------------------------------------------------
>
> Key: AVRO-2400
> URL: https://issues.apache.org/jira/browse/AVRO-2400
> Project: Apache Avro
> Issue Type: Bug
> Components: java
> Reporter: Jacob Tolar
> Priority: Blocker
> Fix For: 1.10.0, 1.9.1
>
>
> The failure occurs in ResolvingGrammarGenerator when reader and writer schema
> have an array of records with different full names (e.g. different
> namespace).
> {code:java}
> Exception in thread "main" java.lang.ClassCastException:
> org.apache.avro.Resolver$ReaderUnion cannot be cast to
> org.apache.avro.Resolver$Container{code}
> Avro 1.8.2 allowed this behavior but it now fails in 1.9.0. Looking at the
> jiras and code, I don't believe this was intentional ( AVRO-2275,
> [https://github.com/apache/avro/commit/39d959e1c6a1f339f03dab18289e47f27c10be7f]
> ).
>
> It looks like there were some attempts to keep compatibility (
> [https://github.com/apache/avro/blob/branch-1.9/lang/java/avro/src/main/java/org/apache/avro/Resolver.java]
> , e.g. see the commented out check for w.getFullName() in resolve()) but
> this case was missed.
>
> See this simple example to reproduce.
> [https://gist.github.com/jacobtolar/c88d43ab4e8767227891e5cdc188ffad]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
