-
-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Gracefully skip serialization of properties backed by non-serializable objects #54
Comments
So messing around with this for a while, I've found that By the same token, it would be nice to be able to skip serialization of entire parameters through some type of setting to omit any member that is of a certain class (in this example, |
I ended up implementing a custom serializer for the object type in question, but I think there's still room for the ability to skip a serialization without being able to annotate the object in question. |
Hi @bradjones1, there is a |
After re-reading it I see that my suggestion is not an option. |
@bradjones1 coming back to this. For the next version I've extracted an interface, which should help with the class being final. That said, the current definition provider has a DefaultSerializerRepository and a DefaultCasterRepository which allows you to assign casters and serializer based on a type. Wouldn't that fit your situation? |
I am using this library to serialize value objects provided by
commerceguys/addressing
, that is, a library I do not maintain in-tree.One of the properties of the object I am serializing is defined as
None of these classes has the kind of typed return values
object-hydrator
is looking for, so it fails withUnable to serialize object
on the parent object being serialized. It would be nice if the library could gracefully skip properties which are not serializable for whatever reason. I understand that in many cases failing early would be preferable (that is, when writing your own code that needs to be symmetrically serializable. But in other cases, such as using this library to predictably serialize value objects of various types, we can be a little more liberal.If I owned the code in question then I could annotate the properties to be skipped. But since this is out-of-tree, I need to be able to handle this condition from outside. I'm going to experiment with a customized service(s) to
DefinitionProvider
to do something like this?The text was updated successfully, but these errors were encountered: