Skip to content
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

Open
bradjones1 opened this issue Jul 3, 2023 · 5 comments

Comments

@bradjones1
Copy link
Contributor

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

/**
 * Gets the subdivision children.
 *
 * @return ArrayCollection|LazySubdivisionCollection The subdivision children.
 */
public function getChildren(): Collection
{
    return $this->children;
}

None of these classes has the kind of typed return values object-hydrator is looking for, so it fails with Unable 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?

@bradjones1
Copy link
Contributor Author

bradjones1 commented Jul 4, 2023

So messing around with this for a while, I've found that DefinitionProvider is final, so no overriding its methods. It seems there's no way to do what I'm discussing by passing a custom implementation of any of its dependent services (as passed to the constructor) but what about an extra argument to the constructor to say, skip any property for which a type cannot be determined? We could keep the current behavior the same (fail early) while maintaining some flexibility around serializing objects that can't be annotated.

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, Collection) or particular named properties? I think this is related in spirit to #47.

@bradjones1
Copy link
Contributor Author

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.

@frankdejonge
Copy link
Member

Hi @bradjones1, there is a DoNotSerialize attribute to prevent a property from being serialized, would that have helped you out?

@frankdejonge
Copy link
Member

After re-reading it I see that my suggestion is not an option.

@frankdejonge
Copy link
Member

@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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants