doctrine/archived-orm

mirror of https://github.com/doctrine/orm.git synced 2026-03-23 22:42:18 +01:00

DDC-2487: UnitOfWork::getEntityIdentifier() contains objects when custom mapping types are part of an entity's identity #3124

New Issue

Closed

opened 2026-01-22 14:12:56 +01:00 by admin · 7 comments

admin commented

2026-01-22 14:12:56 +01:00

Owner

Originally created by @doctrinebot on GitHub (Jun 4, 2013).

Originally assigned to: @beberlei on GitHub.

Jira issue originally created by user benjamin:

I'm using a custom mapping type for a LocalDate class (mapped to a DATE field in the MySQL database).

Given the following entity:

/****
 * @Entity
 */
class Timeslot
{
    /****
     * @Id
     * @ManyToOne(targetEntity="Restaurant")
     */
    protected $restaurant;

    /****
     * @Id
     * @Column(type="localdate")
     */
    protected $date;
}

When var_export() -ing the result of UnitOfWork::getEntityIdentifier() on an instance of this class, the result is similar to:

array(
    'restaurant' => '5',
    'date' => LocalDate::*_set*state(array('year' => 2013, 'month' => 6, 'day' => 26))
)

This is a bit weird, because as far as I understand it, it should return the identity as it maps to database fields:

array(
    'restaurant' => '5',
    'date' => '2013-06-26'
)

If we take the $restaurant example, it returns the restaurant ID, and not the Restaurant entity, so my opinion is that it should be the same for $date.

Shouldn't the UnitOfWork use Type::convertToDatabaseValue() on custom mapping types to infer their value, when computing the identity of an entity?

Originally created by @doctrinebot on GitHub (Jun 4, 2013). Originally assigned to: @beberlei on GitHub. Jira issue originally created by user benjamin: I'm using a custom mapping type for a `LocalDate` class (mapped to a `DATE` field in the MySQL database). Given the following entity: ``` /**** * @Entity */ class Timeslot { /**** * @Id * @ManyToOne(targetEntity="Restaurant") */ protected $restaurant; /**** * @Id * @Column(type="localdate") */ protected $date; } ``` When `var_export()` -ing the result of `UnitOfWork::getEntityIdentifier()` on an instance of this class, the result is similar to: ``` array( 'restaurant' => '5', 'date' => LocalDate::*_set*state(array('year' => 2013, 'month' => 6, 'day' => 26)) ) ``` This is a bit weird, because as far as I understand it, it should return the identity as it maps to database fields: ``` array( 'restaurant' => '5', 'date' => '2013-06-26' ) ``` If we take the `$restaurant` example, it returns the restaurant ID, and not the `Restaurant` entity, so my opinion is that it should be the same for `$date`. Shouldn't the `UnitOfWork` use `Type::convertToDatabaseValue()` on custom mapping types to infer their value, when computing the identity of an entity?

admin added the Bug label 2026-01-22 14:12:56 +01:00

admin closed this issue

2026-01-22 14:12:57 +01:00

admin commented

2026-01-22 14:12:58 +01:00

Author

Owner

@doctrinebot commented on GitHub (Jun 4, 2013):

is duplicated by DDC-3377: DateTime columns cannot be used with @Id

@doctrinebot commented on GitHub (Jun 4, 2013): - is duplicated by [DDC-3377: DateTime columns cannot be used with @Id](http://www.doctrine-project.org/jira/browse/DDC-3377)

admin commented

2026-01-22 14:12:58 +01:00

Author

Owner

@doctrinebot commented on GitHub (Jun 4, 2013):

Comment created by @ocramius:

[~benjamin] why would getEntityIdentifier convert types? The UoW doesn't worry about the DBAL representation of the objects - actually, the UoW doesn't know of the DBAL at all.

@doctrinebot commented on GitHub (Jun 4, 2013): Comment created by @ocramius: [~benjamin] why would getEntityIdentifier convert types? The UoW doesn't worry about the DBAL representation of the objects - actually, the UoW doesn't know of the DBAL at all.

admin commented

2026-01-22 14:12:58 +01:00

Author

Owner

@doctrinebot commented on GitHub (Jun 4, 2013):

Comment created by benjamin:

Your point is valid, but that's still annoying. Why would getEntityIdentifier() return objects?
By the way, UnitOfWork is aware of EntityManager, and thus the Connection, and thus the Platform!
It does use the Connection in commit().

@doctrinebot commented on GitHub (Jun 4, 2013): Comment created by benjamin: Your point is valid, but that's still annoying. Why would getEntityIdentifier() return objects? By the way, `UnitOfWork` is aware of `EntityManager`, and thus the `Connection`, and thus the `Platform`! It does use the `Connection` in `commit()`.

admin commented

2026-01-22 14:12:58 +01:00

Author

Owner

@doctrinebot commented on GitHub (Jun 4, 2013):

Comment created by @ocramius:

[~benjamin] that is because that is the identifier in your object. It's composed by the identifier of an associated entity and a datetime object (scalar)

@doctrinebot commented on GitHub (Jun 4, 2013): Comment created by @ocramius: [~benjamin] that is because that is the identifier in your object. It's composed by the identifier of an associated entity and a datetime object (scalar)

admin commented

2026-01-22 14:12:59 +01:00

Author

Owner

@doctrinebot commented on GitHub (Jun 4, 2013):

Comment created by benjamin:

[~ocramius] Then why does it return the restaurant ID, and not the Restaurant object?

@doctrinebot commented on GitHub (Jun 4, 2013): Comment created by benjamin: [~ocramius] Then why does it return the restaurant ID, and not the `Restaurant` object?

admin commented

2026-01-22 14:12:59 +01:00

Author

Owner

@doctrinebot commented on GitHub (Dec 22, 2013):

Comment created by @beberlei:

This is not a bug, it is just how it works, the docblock says nothing about how the fields have to look. The UnitOfWork API is mostly serving itself and optimized for that.

@doctrinebot commented on GitHub (Dec 22, 2013): Comment created by @beberlei: This is not a bug, it is just how it works, the docblock says nothing about how the fields have to look. The UnitOfWork API is mostly serving itself and optimized for that.

admin commented

2026-01-22 14:13:00 +01:00

Author

Owner

@doctrinebot commented on GitHub (Dec 22, 2013):

Issue was closed with resolution "Invalid"

@doctrinebot commented on GitHub (Dec 22, 2013): Issue was closed with resolution "Invalid"

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: doctrine/archived-orm#3124