Customize the comparator for custom mapping types #6340

New Issue

admin · 2026-01-22T15:31:21+01:00

admin commented

2026-01-22 15:31:21 +01:00

Originally created by @babaorum on GitHub (Nov 7, 2019).

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).

Originally created by @babaorum on GitHub (Nov 7, 2019). ### 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](https://www.doctrine-project.org/projects/doctrine-orm/en/2.6/cookbook/advanced-field-value-conversion-using-custom-mapping-types.html)) 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).

admin closed this issue

2026-01-22 15:31:21 +01:00

admin commented

2026-01-22 15:31:23 +01:00

@SenseException commented on GitHub (Nov 11, 2019):

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

@SenseException commented on GitHub (Nov 11, 2019): Thank you for your thoughts putting into this issue. This was discussed in #7583 and #7586 where DateTime types were an issue.

admin commented

2026-01-22 15:31:23 +01:00

@babaorum commented on GitHub (Nov 12, 2019):

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).

@babaorum commented on GitHub (Nov 12, 2019): Sorry, I was not able to find this issue myself. I found the [documentation](https://www.doctrine-project.org/projects/doctrine-orm/en/2.6/cookbook/working-with-datetime.html#datetime-changes-are-detected-by-reference) 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](https://www.doctrine-project.org/projects/doctrine-orm/en/2.6/cookbook/custom-mapping-types.html). 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).

admin commented

2026-01-22 15:31:23 +01:00

@beberlei commented on GitHub (Dec 1, 2019):

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.

@beberlei commented on GitHub (Dec 1, 2019): 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.`

admin commented

2026-01-22 15:31:23 +01:00

@PowerKiKi commented on GitHub (Oct 25, 2020):

Interestingly beberlei himself opened a issue about this a long time ago. It now has an interesting discussion about several aspects of it: https://github.com/doctrine/orm/issues/5542

@PowerKiKi commented on GitHub (Oct 25, 2020): Interestingly beberlei himself opened a issue about this a long time ago. It now has an interesting discussion about several aspects of it: https://github.com/doctrine/orm/issues/5542

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: doctrine/archived-orm#6340