Doctrine 2 - ORM
  1. Doctrine 2 - ORM
  2. DDC-2487

UnitOfWork::getEntityIdentifier() contains objects when custom mapping types are part of an entity's identity

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Invalid
    • Affects Version/s: 2.3.4
    • Fix Version/s: None
    • Component/s: ORM
    • Security Level: All
    • Labels:

      Description

      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?

        Issue Links

          Activity

          Hide
          Marco Pivetta added a comment -

          Benjamin Morel 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.

          Show
          Marco Pivetta added a comment - Benjamin Morel 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.
          Hide
          Benjamin Morel added a comment - - edited

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

          Show
          Benjamin Morel added a comment - - edited 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() .
          Hide
          Marco Pivetta added a comment -

          Benjamin Morel 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)

          Show
          Marco Pivetta added a comment - Benjamin Morel 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)
          Hide
          Benjamin Morel added a comment -

          Marco Pivetta Then why does it return the restaurant ID, and not the Restaurant object?

          Show
          Benjamin Morel added a comment - Marco Pivetta Then why does it return the restaurant ID, and not the Restaurant object?
          Hide
          Benjamin Eberlei added a comment -

          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.

          Show
          Benjamin Eberlei added a comment - 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.

            People

            • Assignee:
              Benjamin Eberlei
              Reporter:
              Benjamin Morel
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: