You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@avro.apache.org by "Theodlz (via GitHub)" <gi...@apache.org> on 2026/01/24 21:26:32 UTC

[I] support for serde_as: skip_serializing_none [avro-rs]

Theodlz opened a new issue, #434:
URL: https://github.com/apache/avro-rs/issues/434

   Hi! Thank you so much for the work you've put in the serde integration. We used to have a custom crate to overwrite some of the behavior of older versions of this package (to respect some of the serde macros), but I gave a go at using what's now on main and it works great!!!
   
   I only have one comment. it's not uncommon to have large structs, and for these to have a bunch of optional fields. When that happens, one might want to not serialize the None fields (say you are writing documents to a database, outputting data as JSON for an API, ...). There, folks often use the `serde_as` crate, as such:
   ```rust
   #[serde_as]
   #[skip_serializing_none]
   #[derive(Deserialize, Serialize)]
   struct Test {
     a: i64,
     b: Option<String>
   }
   ```
   
   here with just one optional fields it's just overkill, but when you have a lot of them it's very elegant to use that "struct-wide" `#[skip_serializing_none]` rather than having to set a skip serialize macro on all optional fields. Unfortunately, that doesn't seem to work at the moment (previous version of the code actually didn't complain about these things, likely because it ignored serde stuff altogether?). Instead, it shows me this error:
   ```
   #[serde(skip_serializing)]` and `#[serde(skip_serializing_if)]` require `#[avro(default = "..")]
   ```
   That is solved by, as stated, adding a `#[avro(default = "null")` on all the optional fields of the struct.
   
   So, it would be a bit more elegant if it could just automatically infer that the default should be null/None for these optional fields, so we could still use `serde_as + skip_serializing_none`


-- 
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: issues-unsubscribe@avro.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [I] support for serde_as: skip_serializing_none [avro-rs]

Posted by "Kriskras99 (via GitHub)" <gi...@apache.org>.
Kriskras99 closed issue #434: support for serde_as: skip_serializing_none
URL: https://github.com/apache/avro-rs/issues/434


-- 
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: issues-unsubscribe@avro.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [I] support for serde_as: skip_serializing_none [avro-rs]

Posted by "Kriskras99 (via GitHub)" <gi...@apache.org>.
Kriskras99 commented on issue #434:
URL: https://github.com/apache/avro-rs/issues/434#issuecomment-3796299670

   Maybe we could do the following:
   1. Extend `AvroSchemaComponent` with a `default` function
   ```rust
   /// Set the default value for this type if it is used in a record.
   ///
   /// Provided implementation returns `None` indicating that this type does not have a default value.
   fn default() -> Option<serde_json::Value> {
       None
   }
   ```
   2. Implement it for `Option<T>`
   ```rust
   impl<T: AvroSchemaComponent> AvroSchemaComponent for T {
       fn default() -> Option<serde_json::Value> {
           Some(serde_json::Value::Null)
       }
   }
   ```
   3. Enable users to derive the implementation by adding the container attribute `default`
   ```rust
   #[derive(AvroSchema)]
   #[avro(default = "A")]
   enum Foo {
       A,
       B,
   }
   ```
   4. Enable users to disable using the default for a type
   ```rust
   #[derive(AvroSchema)]
   struct Bar {
       #[avro(default = false)]
       foo: Foo
   }
   ```
   5. In the derive implementation we would first look if the user set a override via the field attribute `default` and then fall back to the trait. This would mean that all `Option`s would have a default in the next release.
   
   @martin-g what do you think?


-- 
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: issues-unsubscribe@avro.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org