UnitOfWork does not distinguish between empty string or boolean false when hashing identifiers #5178

New Issue

admin · 2026-01-22T15:00:51+01:00

admin commented

2026-01-22 15:00:51 +01:00

Originally created by @Ocramius on GitHub (Jul 7, 2016).

Specifically, when new entities are registered in the identity map, no type information is maintained inside the hashed identifier.

This makes the code quite fragile, and allows for ugly edge-case scenarios:

what if two different identifiers cast to the same string representation? (for example, true and 1, false and '')
what if the identifier of an entity allows integer, boolean and string values?

A solution would be to store type information (about the identifier) into the generated hash. This can easily be done with json_encode(), for example (note that it would be incompatible with object identifier values), or by array_map()-ing over the values (slow: potentially a performance killer).

Originally created by @Ocramius on GitHub (Jul 7, 2016). Specifically, when [new entities are registered in the identity map](https://github.com/doctrine/doctrine2/blob/5761d07c46682e6adc0aa84b4647e15b709adc26/lib/Doctrine/ORM/UnitOfWork.php#L1401), no type information is maintained inside the hashed identifier. This makes the code quite fragile, and allows for ugly edge-case scenarios: - what if two different identifiers cast to the same string representation? (for example, `true` and `1`, `false` and `''`) - what if the identifier of an entity allows integer, boolean and string values? A solution would be to store type information (about the identifier) into the generated hash. This can easily be done with `json_encode()`, for example (note that it would be incompatible with object identifier values), or by `array_map()`-ing over the values (slow: potentially a performance killer).

admin added the Bug label 2026-01-22 15:00:51 +01:00

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#5178