Incompatibility with rich data objects (PHP 7+, Data casting)

[scaytrase]

If we

• have a PHP 7.0 +
• entity with \DateTime property
• timestamp as raw ("database") data
• getter for property annotated with : \DateTime return type

Expected result:
\DateTime entity is returned on getter call

Actual result:
Type error, since no data casting is involved on hyrating

As a result we have an inconsistent entity after hydration

From https://samdark.github.io/blog/hydrator/#comment-3306475417

[TemirkhanN]

@scaytrase I am not sure that hydrating objects that have embedded objects "magically" is good idea. That must be some kind of exact Hydrator that implements HydratorInterface. I mean, it is not so diffucult to parse property annotation and detect what kind of another hydrator(DateTimeHydrator) shall be used to hydrate that property. But if property is declared as Interface? Let it be DateTimeInterface. What shall hydrator choose: DateTime, DateTimeImmutable?

[TemirkhanN]

For now you can extend basic hydrator and make rich transformations there.
Kind of
https://gist.github.com/TemirkhanN/0fd90d18f236ca24291d7955d29ee7a6

[scaytrase]

@TemirkhanN Sure it is not a good idea to deal this magically, I'm just pointing that current implementation is valid only for POJO classes with no objects inside.

For me the only proper solution here is to have some kind of mapping metadata, like JMS or Doctrine have.

Extending hydrator for each used class would be terrible to maintain if you have something bigger that Post|Author classmap, especially hell it will be if you want to dehydrate VO chain inside your class (I.e you have Product::class which has $cost which is Money:class which has $currency which is Currency::class)

[TemirkhanN]

@scaytrase for some reason Doctrine is encapsulating hydration in it. I mean If you need object relationship management it might be you need something more than hydrator itself.

What about "extending mess" it won't be such awful as you describe it. Yes, there will be a lot of hydrators in big system but composition makes things easy as you pass dependencies to required level nest.

ProductHydrator::__construct(HydratorInterface $costHydrator);
CostHydrator::__construct(HydratorInterface $moneyHydrator);
MoneyHydrator::__construct(HydratorInterface $currencyHydrator);

[scaytrase]

1. Interfaces won't work, you have to know, that concrete hydrator supporting specified class. Binding to interface would be a mistake since invalid hydrator will lead to unexpected errors in logic.
2. You have to properly configure each hydrator, moreover you might have different configuration for different field of the same class (i.e you can have \DateTimeHydrator with different format configured). This already leads to some kind of configuration a.k.a mapping metadata.
3. Proper configuration leads to some kind of DI involving, so you have discover and load your hydrator configuration, welcome metadata factories
4. You will have exact hydrators hierarchy as you entities have, so there is more sence to move this logic to the entity itself using i.e traits. This also simplify the hydartor code, as soon as reflection will not be needed to access class properties to hydrate

You are correct about Doctirne encapsulation, but in general the open question is how to resolve relationship from "dehydrated" data, i.e IDs to entity or proxy or something like that, also opaque things like owning side of toMany associations, when no clean data present in dehydrated data.

With abstraction of this question own metadata could be build, one was done in JMS