Summary
First of all, thank you very much for your work on avro-rs! The SchemaAwareDeserializer introduced in #512 is a great addition.
I would like to kindly ask about the status of the resolving counterpart to that deserializer. Today, SchemaAwareDeserializer decodes directly into T only when the reader schema matches the writer schema. As soon as a reader schema differs , the serde path deliberately bails out with a todo!/panic!, pointing at a not-yet-implemented SchemaAwareResolvingDeserializer.
I haven't found a tracking ticket for this.
Where this shows up in the code
The gap is marked with three matching TODOs on main(pinned to 660c655cac0cdf3bc5c6818bf6b5e445eb09bdce):
GenericDatumReader::read_deser
avro/src/reader/datum.rs#L149-L150
// TODO: Implement SchemaAwareResolvingDeserializer
panic!("Schema aware deserialisation does not resolve schemas yet");Reader (object-container path)
avro/src/reader/mod.rs#L134-L137
// TODO: Implement SchemaAwareResolvingDeserializer
...
"Schema aware deserialisation does not resolve schemas yet"
BlockReader
avro/src/reader/block.rs#L233-L234
// TODO: Implement SchemaAwareResolvingDeserializer
panic!("Schema aware deserialisation does not resolve schemas yet");
The non-resolving deserializer itself lives in avro/src/serde/deser_schema/mod.rs and carries a single schema, doing no writer→reader resolution.
Why it matters
Currently, schema evolution is only available on the Value route: decode to Value against the writer schema, then Value::resolve* against the reader schema, then optionally from_value::<T>(). This allocates a full Value tree (and, without a cached ResolvedSchema, a fresh name map) per record — precisely the overhead the schema-aware deserializer was designed to avoid. A resolving deserializer would close that gap and, as noted in the #512 description, could eventually allow deprecating from_value / to_value entirely.
Request
Would you be willing to share the implementation state of a SchemaAwareResolvingDeserializer?
I completely understand this is volunteer-maintained work and that priorities and timelines shift; please take this only as gentle interest, not pressure!
Thanks,
@flxo
Summary
First of all, thank you very much for your work on
avro-rs! TheSchemaAwareDeserializerintroduced in #512 is a great addition.I would like to kindly ask about the status of the resolving counterpart to that deserializer. Today,
SchemaAwareDeserializerdecodes directly intoTonly when the reader schema matches the writer schema. As soon as a reader schema differs , the serde path deliberately bails out with atodo!/panic!, pointing at a not-yet-implementedSchemaAwareResolvingDeserializer.I haven't found a tracking ticket for this.
Where this shows up in the code
The gap is marked with three matching
TODOs onmain(pinned to660c655cac0cdf3bc5c6818bf6b5e445eb09bdce):GenericDatumReader::read_deseravro/src/reader/datum.rs#L149-L150
Reader(object-container path)avro/src/reader/mod.rs#L134-L137
BlockReaderavro/src/reader/block.rs#L233-L234
The non-resolving deserializer itself lives in avro/src/serde/deser_schema/mod.rs and carries a single schema, doing no writer→reader resolution.
Why it matters
Currently, schema evolution is only available on the
Valueroute: decode toValueagainst the writer schema, thenValue::resolve*against the reader schema, then optionallyfrom_value::<T>(). This allocates a fullValuetree (and, without a cachedResolvedSchema, a fresh name map) per record — precisely the overhead the schema-aware deserializer was designed to avoid. A resolving deserializer would close that gap and, as noted in the #512 description, could eventually allow deprecatingfrom_value/to_valueentirely.Request
Would you be willing to share the implementation state of a
SchemaAwareResolvingDeserializer?I completely understand this is volunteer-maintained work and that priorities and timelines shift; please take this only as gentle interest, not pressure!
Thanks,
@flxo