Hello! From my reading of the spec, I would expect that adding any field without a default property to cause an incompatibility, and I wouldn't expect nullables to be a special case.
In context, the referenced sentence is a suggestion to put null first in the schema, because null can be a pretty common placeholder for missing data. It's not implying that null is automatically the default value. "Thus, for unions containing "null", the "null" is usually listed first, since the default value of such unions is typically null." So there currently isn't any "implicit" default value used for schema resolution. I wouldn't object to changing that! The positive point about the current rules is that the "schema designer" is forced to explicitly think about the impact of adding the field. All my best, Ryan On Fri, Feb 5, 2021 at 1:45 PM Csaba Galyo <[email protected]> wrote: > Hello, > > > > I was looking at an older issue which was present in 1.7 and 1.8 and was > wondering if it has been resolved in 1.9? > > > > In the documentation for 1.8 and 1.9 ( > https://avro.apache.org/docs/1.9.2/spec.html#Unions ) we can read that > “the > default value of such unions is typically null”. > > > > When we check for compatibility between reader and writer, we assume that > the writer contains the same field or that the reader has a default value. > An error is returned if there is no default value: > > > > > https://github.com/apache/avro/blob/master/lang/java/avro/src/main/java/org/apache/avro/SchemaCompatibility.java#L404 > > > > There is a special case for enums, but no special case for unions. Assuming > we have a field like below, are we going to get an error? > > > > { "name": "year", "type": ["null", "string"] } > > > > According to the docs, this should still work even without a default value, > because the default value of such a union would be null. > > > > Do I interpret this right? > > > > Thanks, > > Csaba >
