[
https://issues.apache.org/jira/browse/AVRO-2322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16779745#comment-16779745
]
Doug Cutting commented on AVRO-2322:
AVRO-1590 seems like an instance of Postel's law (liberal in what's accepted,
strict in what's produced). When a union contains no perfect match but does
contains a match that is structurally identical but differently named, that is
accepted by the Java implementation. I think this was for back-compatibility:
record names have not always been validated consistently on read. But written
data should never mismatch its schema.
Validation, if used to check for cross-language compatibility, should arguably
not be so liberal. That said, there may be applications that depend on this.
Does that help?
> Compatibility checks report false positive when record fullnames differ
> ---
>
> Key: AVRO-2322
> URL: https://issues.apache.org/jira/browse/AVRO-2322
> Project: Apache Avro
> Issue Type: Bug
> Components: java
>Affects Versions: 1.8.1, 1.8.2
>Reporter: Chris Egerton
>Priority: Major
>
> When testing for backward compatibility between two record schemas which
> differ in their fullnames (namespace + name) but are otherwise identical, a
> false positive is reported.
> Example:
> {code:java}
> // Create two schemas with differing fullnames and no fields
> Schema writtenSchema = Schema.createRecord("write", null, "namespace", false,
> Collections.emptyList());
> Schema readSchema = Schema.createRecord("read", null, "namespace", false,
> Collections.emptyList());
> // Validate the two schemas for compatibility
> // Should throw a SchemaValidationException; does not
> new
> SchemaValidatorBuilder().canReadStrategy().validateLatest().validate(readSchema,
> Collections.singleton(writtenSchema));{code}
> It looks like this behavior partially stems from discussion on AVRO-1590,
> although I'm unfortunately not familiar enough with some of the concepts
> brought up there to understand why it's advantageous to deviate from the spec
> like this.
> I'd be happy to work on a fix myself; just want to understand how to
> implement this correctly without stepping on the decisions of others before
> opening a PR.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
