Bi-directional OneToOne not loaded when using custom DBAL types #5959

New Issue

Closed

opened 2026-01-22 15:23:11 +01:00 by admin · 5 comments

admin commented 2026-01-22 15:23:11 +01:00

Owner

Copy Link

Originally created by @dekker-m on GitHub (May 1, 2018).

Originally assigned to: @Ocramius on GitHub.

Some days ago we mapped some legacy database to Doctrine. It went well, however, we ran into an issue today with a bi-directional one-to-one association. The association uses custom DBAL types as join columns. This creates an issue when loading the entity. From what we found, the following is happening:

1. Entity A is loaded from the database, this entity is loaded correctly. The primary key from A is a custom DBAL type (a UUID stored as an BINARY(16), let's call the DBAL type "binary_uuid"). In the DBAL SQL Logger we see the query is executed as expected, the parameter for the query is a UUID in the form "00000000-0000-0000-0000-000000000000". The type of the parameter is given as "binary_uuid".
2. Entity B, the owning side of the association, is loaded automatically by the method BasicEntityPersister::loadOneToOneEntity(). Using the DBAL SQL Logger we see that the correct SQL is being executed to load the entity. However, the parameter and/or the type of the parameters are wrong. The parameter is again an UUID in the above mention form, however the type of the parameter is not detected at all. Because an UUID in the above mentioned form does not match the BINARY(16) column in the database, no record is returned.

I'm not sure if this is a scenario which is supported by Doctrine and if this would be an improvement or a bug, but from what I can see by looking at the BasicEntityPersister, it would be possible to load those associations correctly. The reason why BasicEntityPersister::getTypes() is not recognizing the type of the fields correctly is because loadOneToOneEntity() passes an SQL column to the load() method. getTypes() looks at the mapping for object properties instead of SQL columns.

I'm not that familiar with the doctrine codebase, but from what I can see there could be two possible fixes to support loading entities with custom types as join column (at least for one-to-one associations).

1. In loadOneToOneEntity() the methods Type::getType() and PersisterHelper::getTypeOfColumn() can be used to get the type of the column and convert the value to a database value using the type's method convertToDatabaseValue. This is a solution I tested locally and this seems to work. However, I can understand this might not be the best solution, because the executeQuery method on the connection has a $types parameter for a reason. If for some reason the type of the parameter is recognized after all, this would cause the conversion to happen twice.
2. loadOneToOneEntity() is now passing the identifiers to load() using SQL columns. However, load() already seems to take care of the conversion from property names/association names to SQL column names. Instead of using SQL columns in the identifier, why not use the association name of the target class? For example:

$identifier = [$owningAssoc['fieldName'] => $sourceEntity];

This seems to load the entities as well, and lets the load() method take care of the property to SQL column mapping. I tested this solution as well and it seems to work. I can't really think of a downside of this solution, nor of any side effects.

I tested this against the following packages:

doctrine/annotations                     v1.6.0 
doctrine/cache                           v1.7.1
doctrine/collections                     v1.5.0
doctrine/common                          v2.8.1
doctrine/data-fixtures                   v1.3.0
doctrine/dbal                            v2.6.3
doctrine/inflector                       v1.3.0
doctrine/instantiator                    1.1.0
doctrine/lexer                           v1.0.1
doctrine/orm                             v2.5.14

Could the second solution work without introducing any side effects? If so, I might be able to write a pull request.

Originally created by @dekker-m on GitHub (May 1, 2018). Originally assigned to: @Ocramius on GitHub. Some days ago we mapped some legacy database to Doctrine. It went well, however, we ran into an issue today with a bi-directional one-to-one association. The association uses custom DBAL types as join columns. This creates an issue when loading the entity. From what we found, the following is happening: 1. Entity A is loaded from the database, this entity is loaded correctly. The primary key from A is a custom DBAL type (a UUID stored as an BINARY(16), let's call the DBAL type "binary_uuid"). In the DBAL SQL Logger we see the query is executed as expected, the parameter for the query is a UUID in the form "00000000-0000-0000-0000-000000000000". The type of the parameter is given as "binary_uuid". 2. Entity B, the owning side of the association, is loaded automatically by the method `BasicEntityPersister::loadOneToOneEntity()`. Using the DBAL SQL Logger we see that the correct SQL is being executed to load the entity. However, the parameter and/or the type of the parameters are wrong. The parameter is again an UUID in the above mention form, however the type of the parameter is not detected at all. Because an UUID in the above mentioned form does not match the BINARY(16) column in the database, no record is returned. I'm not sure if this is a scenario which is supported by Doctrine and if this would be an improvement or a bug, but from what I can see by looking at the `BasicEntityPersister`, it would be possible to load those associations correctly. The reason why `BasicEntityPersister::getTypes()` is not recognizing the type of the fields correctly is because `loadOneToOneEntity()` passes an SQL column to the `load()` method. `getTypes()` looks at the mapping for object properties instead of SQL columns. I'm not that familiar with the doctrine codebase, but from what I can see there could be two possible fixes to support loading entities with custom types as join column (at least for one-to-one associations). 1. In `loadOneToOneEntity()` the methods `Type::getType()` and `PersisterHelper::getTypeOfColumn()` can be used to get the type of the column and convert the value to a database value using the type's method `convertToDatabaseValue`. This is a solution I tested locally and this seems to work. However, I can understand this might not be the best solution, because the `executeQuery` method on the connection has a `$types` parameter for a reason. If for some reason the type of the parameter is recognized after all, this would cause the conversion to happen twice. 2. `loadOneToOneEntity()` is now passing the identifiers to `load()` using SQL columns. However, `load()` already seems to take care of the conversion from property names/association names to SQL column names. Instead of using SQL columns in the identifier, why not use the association name of the target class? For example: ```php $identifier = [$owningAssoc['fieldName'] => $sourceEntity]; ``` This seems to load the entities as well, and lets the `load()` method take care of the property to SQL column mapping. I tested this solution as well and it seems to work. I can't really think of a downside of this solution, nor of any side effects. I tested this against the following packages: ``` doctrine/annotations v1.6.0 doctrine/cache v1.7.1 doctrine/collections v1.5.0 doctrine/common v2.8.1 doctrine/data-fixtures v1.3.0 doctrine/dbal v2.6.3 doctrine/inflector v1.3.0 doctrine/instantiator 1.1.0 doctrine/lexer v1.0.1 doctrine/orm v2.5.14 ``` Could the second solution work without introducing any side effects? If so, I might be able to write a pull request.

admin added the BugInvalidMissing Tests labels 2026-01-22 15:23:11 +01:00

admin closed this issue 2026-01-22 15:23:11 +01:00

admin commented 2026-01-22 15:23:12 +01:00

Author

Owner

Copy Link

@oleg-andreyev commented on GitHub (Oct 5, 2018):

We've faced same issue with custom types (uuid), we've figure out how to handle it by adding

case strpos($field, '.') !== false && !count($types):
               $columnName = substr($field, strpos($field, '.') + 1);
               $types[] = PersisterHelper::getTypeOfColumn($columnName, $this->class, $this->em);
               break;

to \Doctrine\ORM\Persisters\Entity\BasicEntityPersister::getTypes, but:

• we cannot alter getTypes because it's private
• we cannot replace BasicEntityPersister with own implementation, because it's initialized in directly in UnitOfWork (and is based of other persistent)
• we cannot replace UnitOfWork with own implementation, because it's initialized directly in EntityManager

@oleg-andreyev commented on GitHub (Oct 5, 2018): We've faced same issue with custom types (uuid), we've figure out how to handle it by adding ``` case strpos($field, '.') !== false && !count($types): $columnName = substr($field, strpos($field, '.') + 1); $types[] = PersisterHelper::getTypeOfColumn($columnName, $this->class, $this->em); break; ``` to `\Doctrine\ORM\Persisters\Entity\BasicEntityPersister::getTypes`, but: - we cannot alter `getTypes` because it's private - we cannot replace `BasicEntityPersister` with own implementation, because it's initialized in directly in `UnitOfWork` (and is based of other persistent) - we cannot replace `UnitOfWork` with own implementation, because it's initialized directly in `EntityManager`

admin commented 2026-01-22 15:23:13 +01:00

Author

Owner

Copy Link

@Ocramius commented on GitHub (Oct 5, 2018):

Replacing/customising is not really what should happen here, @oleg-andreyev: the proper type conversions should happen anyway, and ORM 2.6 includes a lot of fixes to achieve that.

What needs to be done here?

• test case needs to be written
• technical solution (in this repository) can then be written

@Ocramius commented on GitHub (Oct 5, 2018): Replacing/customising is not really what should happen here, @oleg-andreyev: the proper type conversions should happen anyway, and ORM 2.6 includes a lot of fixes to achieve that. What needs to be done here? * test case needs to be written * technical solution (in this repository) can then be written

admin commented 2026-01-22 15:23:13 +01:00

Author

Owner

Copy Link

@oleg-andreyev commented on GitHub (Oct 5, 2018):

@Ocramius thanks for responding. I'll try to prepare test case as soon as possible.

@oleg-andreyev commented on GitHub (Oct 5, 2018): @Ocramius thanks for responding. I'll try to prepare test case as soon as possible.

admin commented 2026-01-22 15:23:13 +01:00

Author

Owner

Copy Link

@oleg-andreyev commented on GitHub (Oct 5, 2018):

@dekker-m @Ocramius after preparing test case, I've found out that this issue is no longer relevant (at least my case OneToOne to JoinedTable entity) in >= v2.6.0

@oleg-andreyev commented on GitHub (Oct 5, 2018): @dekker-m @Ocramius after preparing test case, I've found out that this issue is no longer relevant (at least my case OneToOne to JoinedTable entity) in >= v2.6.0

admin commented 2026-01-22 15:23:13 +01:00

Author

Owner

Copy Link

@Ocramius commented on GitHub (Oct 6, 2018):

Closing as per https://github.com/doctrine/doctrine2/issues/7209#issuecomment-427474070

@dekker-m please submit a test scenario if you manage to reproduce this in 2.6 or newer

@Ocramius commented on GitHub (Oct 6, 2018): Closing as per https://github.com/doctrine/doctrine2/issues/7209#issuecomment-427474070 @dekker-m please submit a test scenario if you manage to reproduce this in 2.6 or newer

Sign in to join this conversation.

No Branch/Tag Specified

Branches Tags

3.6.x

2.20.x

dependabot/github_actions/2.20.x/doctrine/dot-github/dot-github/workflows/composer-lint.yml-14.0.0

3.7.x

4.0.x

2.21.x

old-prototype-3.x

3.6.2

3.6.1

3.6.0

2.20.9

3.5.8

3.5.7

3.5.6

3.5.5

2.20.8

3.5.4

3.5.3

2.20.7

3.5.2

2.20.6

3.5.1

3.5.0

3.4.4

3.4.3

3.4.2

2.20.5

3.4.1

3.4.0

3.3.4

2.20.4

3.3.3

2.20.3

3.3.2

2.20.2

3.3.1

2.20.1

3.3.0

3.2.3

2.20.0

2.19.8

3.2.2

2.19.7

3.2.1

2.19.6

3.2.0

3.1.4

3.1.3

2.19.5

3.1.2

2.19.4

3.1.1

2.19.3

2.19.2

2.19.1

3.1.0

2.19.0

3.0.3

2.18.3

3.0.2

2.18.2

3.0.1

2.18.1

3.0.0

2.18.0

2.17.5

3.0.0-RC1

2.17.4

2.17.3

2.17.2

2.17.1

3.0.0-beta2

2.17.0

2.16.3

3.0.0-beta1

2.16.2

2.16.1

2.16.0

2.15.5

2.15.4

2.15.3

2.15.2

2.15.1

2.15.0

2.14.3

2.14.2

2.14.1

2.14.0

2.13.5

2.13.4

2.13.3

2.13.2

2.13.1

2.13.0

2.12.4

2.12.3

2.12.2

2.12.1

2.12.0

2.11.3

2.11.2

2.11.1

2.11.0

2.10.5

2.10.4

2.10.3

2.10.2

2.10.1

2.10.0

2.9.6

2.9.5

2.9.4

2.9.3

2.9.2

2.9.1

2.9.0

2.8.5

2.8.4

2.8.3

2.8.2

2.8.1

2.8.0

2.7.5

2.7.4

v2.7.3

v2.7.2

v2.7.1

v2.7.0

v2.6.6

v2.6.5

v2.6.4

v2.6.3

v2.6.2

v2.6.1

v2.6.0

v2.5.14

v2.5.13

v2.5.12

v2.5.11

v2.5.10

v2.5.9

v2.5.8

v2.5.7

v2.5.6

v2.5.5

v2.5.4

v2.5.3

v2.5.2

v2.4.8

v2.5.1

v2.5.0

v2.5.0-RC2

v2.5.0-RC1

v2.5.0-beta1

v2.5.0-alpha2

v2.5.0-alpha1

v2.4.7

v2.4.6

v2.4.5

v2.4.4

v2.4.3

v2.3.6

v2.4.2

2.3.5

v2.4.1

v2.4.0

2.4.0-RC2

2.4.0-RC1

2.4.0-BETA2

2.3.4

2.3.3

2.4.0-BETA1

2.3.2

2.3.1

2.3.0

2.3.0-RC4

2.3.0-RC3

2.3.0-RC2

2.2.3

2.3.0-RC1

2.3.0-BETA1

2.1.7

2.2.2

2.2.1

2.1.6

2.2.0

2.2.0-RC1

2.2.0-BETA2

2.2.0-BETA1

2.1.5

2.1.4

2.1.3

2.1.2

2.1.1

2.0.7

2.1.0

2.1.0RC3

2.1.0RC2

2.1.0RC1

2.0.6

2.1.0BETA1

2.0.5

2.0.4

2.0.3

2.0.2

2.0.1

2.0.0

2.0.0RC2

2.0.0RC1

2.0.0-BETA4

2.0.0-BETA3

2.0.0-BETA2

2.0.0-BETA1

Labels

Clear labels

BC Break

Bug

Can't Fix

Deprecation

Documentation

DQL

Duplicate

Failing Test

Hacktoberfest

Improvement

Improvement

Incomplete

Invalid

Missing Tests

New Feature

PR Created

pull-request

Mirrored from GitHub Pull Request

Question

Regression

Status: Waiting feedback

Waiting feedback

WIP

Won't Fix

No Label Bug Invalid Missing Tests

Milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

admin

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: doctrine/archived-orm#5959