martin-g commented on PR #227: URL: https://github.com/apache/avro-rs/pull/227#issuecomment-3116660601
Hi @jdarais ! > I was looking into creating a serde-driven deserializer, but in the end it seemed easier to first deserialize into an avro `Value`, which provides some flexibility that helps with schema resolution (if the reader schema is different from the writer schema,) and then use the existing `de.rs` implementation to convert from `Value` to the final type. The problem here is that the users expect that the schema-driven deserialization in de.rs should take into account the Serde attributes, like the `skip` ones. But maybe as you said we just have to ignore them. Otherwise we will face issues later with attributes like `flatten`, `remote`, etc. But in that case I have no good answer to "I want to use the same serde mechanism for JSON, CSV, Avro, ...) (https://github.com/apache/avro-rs/pull/227#issuecomment-3097968926). > Using the `skip` attribute would be easier to use with Avro since you can just ensure that the skipped field isn't included in the Avro schema used to write. Supporting `skip` is OK. But what to do with `skip_serializing` and `skip_deserialing` ?! We will need to have a field for such fields in the Avro Schema but Serde does not call `skip_field()` when `skip_serializing` is used ... > It might work to just have the `skip_field` implementation do the exact same thing as `serialize_field`, effectively always including the field, since you're not allowed to omit the field anyway. We kinda do this at the moment. * `fn serialize_field<T>(&mut self, key: &'static str, value: &T)` * `fn skip_field(&mut self, key: &'static str)` `skip_field` does not provide the `value`, so we use the `default` from the Avro Schema. This might need some more work! At the moment it is treated as an Option but probably it should be unpacked. > On a different topic: I see from the PR that there was some logic in there before that ensured that struct fields were written in the correct order, (they must be written in the order in which they appear in the schema,) even if the order of the fields in the rust struct is different from what's in the schema. It'd be nice to get that back in. (I realize there should have been a test for it.) You are totally right here! It should work fine when the schema is derived but it will break bad at deserialization time if the schema is created manually! For now we can add a note to the documentation! I removed all logic that didn't break any test :-/ It could be returned with the respective unit tests! -- 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]
