flxo opened a new issue, #575:
URL: https://github.com/apache/avro-rs/issues/575
# 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 `TODO`s on `main`(pinned to
`660c655cac0cdf3bc5c6818bf6b5e445eb09bdce`):
- `GenericDatumReader::read_deser`
[avro/src/reader/datum.rs#L149-L150](https://github.com/apache/avro-rs/blob/660c655cac0cdf3bc5c6818bf6b5e445eb09bdce/avro/src/reader/datum.rs#L149-L150)
```rust
// TODO: Implement SchemaAwareResolvingDeserializer
panic!("Schema aware deserialisation does not resolve schemas yet");
```
- `Reader` (object-container path)
[avro/src/reader/mod.rs#L134-L137](https://github.com/apache/avro-rs/blob/660c655cac0cdf3bc5c6818bf6b5e445eb09bdce/avro/src/reader/mod.rs#L134-L137)
```rust
// TODO: Implement SchemaAwareResolvingDeserializer
...
"Schema aware deserialisation does not resolve schemas yet"
```
- `BlockReader`
[avro/src/reader/block.rs#L233-L234](https://github.com/apache/avro-rs/blob/660c655cac0cdf3bc5c6818bf6b5e445eb09bdce/avro/src/reader/block.rs#L233-L234)
```rust
// 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](https://github.com/apache/avro-rs/blob/660c655cac0cdf3bc5c6818bf6b5e445eb09bdce/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
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
