Support for overriding system hydrators with custom ones

[white-rabbit-1-sketch]

Previously, system hydrators were hardcoded, limiting flexibility for specific use cases. This update introduces functionality to allow developers to override system hydrators with their own custom implementations, providing greater adaptability for unique project requirements.

[beberlei]

We previously decided against this to avoid giving users a way to shoot themselves in the foot. The hydrators are used inside the persisters and interact with the second level cache in ways that not many people can easily grasp.

[white-rabbit-1-sketch]

@beberlei Good day, sir. Please don’t get me wrong, but I feel like this might not be the best approach. With this approach, you could end up removing a lot of useful functionality from Doctrine, like the ability to define relationships between entities through attributes, 'cause - what if someone uses it incorrectly?

Developers generally know what they’re doing, and if someone doesn’t, that’s a reason for him to investigate and learn, rather than blocking or restricting functionality.

I’m one of those people who needed to override the default hydrators. The reason is that there’s an unfixed bug in them, which you’re not willing to fix because of backward compatibility concerns, but that bug is causing me problems (bug about custom data types processing). However, because you’ve restricted the ability to override hydrators, I’m now forced to override half of Doctrine. In the end, I can (!, so you can't really block it, to be honest) override them, but it becomes more difficult and prevents me from taking advantage of easier updates in the future.

I think this decision might need to be reconsidered.