I'm not sure why both SchemaCompatibility and SchemaValidator exist. I think folks perhaps just didn't realize the former existed when the latter was added.
https://issues.apache.org/jira/browse/AVRO-1409 https://issues.apache.org/jira/browse/AVRO-1315 The latter looks like a probably more efficient implementation, since it doesn't compile a parser for each schema validated, but the former shares logic with the reading & writing of data, simplifying maintenance. Doug On Wed, Aug 23, 2017 at 6:01 AM, Nandor Kollar <[email protected]> wrote: > Hi all, > > While I was trying to understand how schema evolution works in Avro, I > noticed that the schema resolution logic ( > https://avro.apache.org/docs/1.8.1/spec.html#Schema+Resolution) is > implemented in two different places in Avro: in ResolvingGrammarGenerator > and in SchemaCompatibility. > > Could someone please explain the differences between > ResolvingGrammarGenerator, SchemaCompatibility, and SchemaValidator? It > seems that SchemaValidator is used to check the compatibility between the > reader and the writer schema, which sounds exactly what SchemaCompatibility > does, why does it use ResolvingGrammarGenerator instead of > SchemaCompatibility? Why is the same schema resolution logic implemented > twice (if I understood correctly)? > > I also have a question related to unions and schema resolution. In the > patch for AVRO-1933 Anders commented out a case for unions: union with an > int branch is not compatible with a long union reader. After a brief > investigation I noticed, that ResolvingGrammarGenerator#bestBranch doesn't > allow int -> float promotion in union branches. Is this a bug? Should we > allow this promotion at all, since like Anders mentioned in AVRO-1931 this > is a lossy conversion? What do you think? > > Thanks, > Nandor >
