DDC-2984: Support Custom DBAL types to be used as identifiers #3713

Closed
opened 2026-01-22 14:25:59 +01:00 by admin · 5 comments
Owner

Originally created by @doctrinebot on GitHub (Feb 15, 2014).

Originally assigned to: @guilhermeblanco on GitHub.

Jira issue originally created by user codeliner:

I've tried to use a Value Object that extends the DBAL\Types\StringType as identifier of an Aggregate Root. This is common practice in DDD, f.e. defining a TrackingId as identifier of a Cargo Aggregate. I've written a unit test for my repository and everything seemed to work well until clearing the UnitOfWork and trying to fetch a fresh entity. The error is similar to the one described in DDC-2176. The issue is closed and I don't understand why?

I think the support of Value Objects is a must have in Doctrine. I've checked out the new feature of defining embedded Value Objects and it works as a charm. But without the option to use Value Objects as identifiers Doctrine is missing an important feature!

Originally created by @doctrinebot on GitHub (Feb 15, 2014). Originally assigned to: @guilhermeblanco on GitHub. Jira issue originally created by user codeliner: I've tried to use a Value Object that extends the DBAL\Types\StringType as identifier of an Aggregate Root. This is common practice in DDD, f.e. defining a TrackingId as identifier of a Cargo Aggregate. I've written a unit test for my repository and everything seemed to work well until clearing the UnitOfWork and trying to fetch a fresh entity. The error is similar to the one described in [DDC-2176](http://www.doctrine-project.org/jira/browse/DDC-2176). The issue is closed and I don't understand why? I think the support of Value Objects is a must have in Doctrine. I've checked out the new feature of defining embedded Value Objects and it works as a charm. But without the option to use Value Objects as identifiers Doctrine is missing an important feature!
admin added the Improvement label 2026-01-22 14:25:59 +01:00
admin closed this issue 2026-01-22 14:26:00 +01:00
Author
Owner

@doctrinebot commented on GitHub (Feb 15, 2014):

Comment created by @ocramius:

DDC-2176 duplicates DDC-1998

Some clarifications:

  • custom types work as identifiers with the ORM as long as object types implement a **toString method that emulates the unique identifier
  • value objects as identifiers are not yet supported and will likely not be supported for another while because of technical limitations

What you can do to help out is writing a test case showing how you would want to use VOs on associations and identifiers.

@doctrinebot commented on GitHub (Feb 15, 2014): Comment created by @ocramius: [DDC-2176](http://www.doctrine-project.org/jira/browse/DDC-2176) duplicates [DDC-1998](http://www.doctrine-project.org/jira/browse/DDC-1998) Some clarifications: - custom types work as identifiers with the ORM as long as object types implement a `**toString` method that emulates the unique identifier - value objects as identifiers are not yet supported and will likely not be supported for another while because of technical limitations What you can do to help out is writing a test case showing how you would want to use VOs on associations and identifiers.
Author
Owner

@doctrinebot commented on GitHub (Feb 16, 2014):

Comment created by codeliner:

thank you for your reply. I have to check with my client if I can spend time to provide a test case. For now, we use the workaround that Yves Berkholz mentioned in his issue DDC-2176 to work with a string represantation of the VO inside the Entity.

The problem is, that the UnitOfWork uses the $idHash as key in the identityMap. If you use a Custom DBAL type as Identifier, the $idHash will be an Object and PHPUnit fails with the error: PHPUnit_Framework_Error_Warning : Illegal offset type in Doctrine\ORM\UnitOfWork.php(2578): ...
Even if the custom type implements a **toString() method.
The error/warning occurs in the same line as of the provided code block of Yves Berkholz:

$this->identityMap[$class->rootEntityName][$idHash] = $entity; // <- 2466 -> now it is line 2578

@doctrinebot commented on GitHub (Feb 16, 2014): Comment created by codeliner: thank you for your reply. I have to check with my client if I can spend time to provide a test case. For now, we use the workaround that Yves Berkholz mentioned in his issue [DDC-2176](http://www.doctrine-project.org/jira/browse/DDC-2176) to work with a string represantation of the VO inside the Entity. The problem is, that the UnitOfWork uses the $idHash as key in the identityMap. If you use a Custom DBAL type as Identifier, the $idHash will be an Object and PHPUnit fails with the error: PHPUnit_Framework_Error_Warning : Illegal offset type in Doctrine\ORM\UnitOfWork.php(2578): ... Even if the custom type implements a **toString() method. The error/warning occurs in the same line as of the provided code block of Yves Berkholz: $this->identityMap[$class->rootEntityName][$idHash] = $entity; // <- 2466 -> now it is line 2578
Author
Owner

@doctrinebot commented on GitHub (Feb 24, 2014):

Comment created by codeliner:

I send a pull request that reproduces the bug in a TestCase, but DoctrineBot has opened a new issue: DDC-2998.

@doctrinebot commented on GitHub (Feb 24, 2014): Comment created by codeliner: I send a pull request that reproduces the bug in a TestCase, but DoctrineBot has opened a new issue: [DDC-2998](http://www.doctrine-project.org/jira/browse/DDC-2998).
Author
Owner

@doctrinebot commented on GitHub (Apr 16, 2014):

Comment created by @guilhermeblanco:

As of 5ce6dabe9b this issue was fixed.

@doctrinebot commented on GitHub (Apr 16, 2014): Comment created by @guilhermeblanco: As of https://github.com/doctrine/doctrine2/commit/5ce6dabe9bb9e81eac6fd261db9bd29f7b7f290c this issue was fixed.
Author
Owner

@doctrinebot commented on GitHub (Apr 16, 2014):

Issue was closed with resolution "Fixed"

@doctrinebot commented on GitHub (Apr 16, 2014): Issue was closed with resolution "Fixed"
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: doctrine/archived-orm#3713