Customize the comparator for custom mapping types

[babaorum]

Feature Request

Q	A
New Feature	yes
RFC	no
BC Break	no

Summary

First of all, I am sorry if this issue should have been created in the doctrine/dbal project.
I realize that it is highly dependent on the doctrine/dbal project for this issue.
I decided to create this issue here, as my current concern is about the job done by the UnitOfWork class to determine which field should be updated.

As of now, every property that is not an association is always compared with the strict comparison operator to determine if the value we want to store in the database is the same or not.

It suits well all PHP scalar types. (no problem there)
But when you are using:

• \DateTime (from date/datetime column types)
• \DateTimeImmutable (from date_immutable/datetime_immutable column types)
• Custom types (example in the doctrine documentation)

A strict comparison may not be the best option.
We can have the same information (for the database) in multiple instances.
Allowing a custom comparison based on the types could help identify which changes should be made.

How to do this

For now, I thought about two ways to handle it.

Comparing using the data to be sent to the database

Instead of comparing the PHP values, comparing the converted values by using the property type Doctrine\DBAL\Types\Type::convertToDatabaseValue() method.

Comparing using a customizable method

In Doctrine\DBAL\Types\Type, we could add a method to compare 2 values of this type.
By default, it could be a strict comparison.
It could be customized for date-related mappings.
It could also be customized for custom types

By default, I would go with the first way, but I am wondering if the second option could not avoid other unnecessary updates (for example JSON with attributes not in the same order).

[SenseException]

Thank you for your thoughts putting into this issue. This was discussed in #7583 and #7586 where DateTime types were an issue.

[babaorum]

Sorry, I was not able to find this issue myself.

I found the documentation explaining this behavior. If we wish to keep it that way, it might be good to also add a reminder in the custom type documentation.

I can understand that we want to preserve this course of action for DateTime.
But I personally find it a bit more disturbing for custom types (being able to be objects as well).

I preferred to open an issue first before doing any development (on doctrine or any of my projects).

[beberlei]

This is documented in custom types, maybe not as explicitly as it could The UnitOfWork never passes values to the database convert method that did not change in the request.

[PowerKiKi]

Interestingly beberlei himself opened a issue about this a long time ago. It now has an interesting discussion about several aspects of it: #5542