In Avro schema evolution, adding a field to a record without a default value is considered which type?

In Avro schema evolution, adding a field to a record without a default value is considered which type?

• A. Forward
• B. Backward
• C. Full
• D. Stable

Answer: (A)

Schema evolution in Avro hinges on how reader and writer schemas relate during decoding. The key idea is that adding or removing fields, and whether those fields have defaults, determines whether newer and older schemas can still interchange data without errors. When you introduce a new field to a record and that field has no default value, the newer schema now expects data for that field to exist. Data written with the older schema obviously doesn’t include this field. During decoding, there’s no value to supply for the new field and no default to fall back on, so the newer reader cannot reliably interpret the old data. In other words, this change breaks compatibility in the forward direction (data written in the past cannot be read by code using the new schema without additional handling). The robust way to preserve compatibility is to provide a default for the new field, which allows old data to be read by the new schema (and vice versa, depending on direction), effectively keeping compatibility for both directions. So, the takeaway is: adding a field without a default value disrupts compatibility, particularly forward compatibility, unless a default is supplied. Providing a default for the new field restores compatibility across evolutions.

Schema evolution in Avro hinges on how reader and writer schemas relate during decoding. The key idea is that adding or removing fields, and whether those fields have defaults, determines whether newer and older schemas can still interchange data without errors.

When you introduce a new field to a record and that field has no default value, the newer schema now expects data for that field to exist. Data written with the older schema obviously doesn’t include this field. During decoding, there’s no value to supply for the new field and no default to fall back on, so the newer reader cannot reliably interpret the old data. In other words, this change breaks compatibility in the forward direction (data written in the past cannot be read by code using the new schema without additional handling). The robust way to preserve compatibility is to provide a default for the new field, which allows old data to be read by the new schema (and vice versa, depending on direction), effectively keeping compatibility for both directions.

So, the takeaway is: adding a field without a default value disrupts compatibility, particularly forward compatibility, unless a default is supplied. Providing a default for the new field restores compatibility across evolutions.