Doctrine 2 - ORM
  1. Doctrine 2 - ORM
  2. DDC-774

Getting the primary key of a reference fetches the object from database

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Won't Fix
    • Affects Version/s: 2.0-BETA3
    • Fix Version/s: None
    • Component/s: None
    • Security Level: All
    • Labels:
      None

      Description

      When creating a reference (i.e. {{ $ref = $em->getReference('\Foo', 1); }}), getting the value of the primary key (i.e. {{ $ref->getId(); }}) fetches the object from the database.

      My understanding ot Doctrine is that the references are proxies to real objects, and that calling any method on them will trigger a fetch from the database, which makes sense.

      May be this could be improved so that proxies have a check like {{ if (I_am_a_reference() and this_is_a_pkey_getter()) return $pkey) }}. This_is_a_pkey_getter() could get its knowledge from some @PrimaryKeyGetter entity annotation.

      The references could then be used in place of the PartialReferences, without the huge WTF-factor of partial references and partial objects.

        Issue Links

          Activity

          Hide
          arnaud-lb added a comment -

          Something like this would be awesome :

          class MyEntity {
          
              /**
               * @Id @Getter('getId')
               */
              $id;
          
              /** declared getter on an @Id property, this method is not proxied / do not triggers database fetches */
              function getId() {
              }
          }
          

          Or this:

          class MyEntity {
          
              /**
                * @NoProxy
                */
              function getId() {
              }
          }
          
          Show
          arnaud-lb added a comment - Something like this would be awesome : class MyEntity { /** * @Id @Getter('getId') */ $id; /** declared getter on an @Id property, this method is not proxied / do not triggers database fetches */ function getId() { } } Or this: class MyEntity { /** * @NoProxy */ function getId() { } }
          Hide
          Roman S. Borschel added a comment - - edited

          We thought about that but there is always the risk that these methods, for whatever reason, have side-effects and/or access other entity state, in which case lazy-loading is completely bypassed. As you already have noticed Doctrine right now can simply not know what is an "id getter" and moreso whether it is free of side-effects.

          Meanwhile you can always get the identifier of any managed object (all "references" are managed, as well as all partial objects and all proxies) without triggering any lazy-loading via:

          $id = $em->getUnitOfWork()->getEntityIdentifier($object);
          

          Hope that helps.

          Show
          Roman S. Borschel added a comment - - edited We thought about that but there is always the risk that these methods, for whatever reason, have side-effects and/or access other entity state, in which case lazy-loading is completely bypassed. As you already have noticed Doctrine right now can simply not know what is an "id getter" and moreso whether it is free of side-effects. Meanwhile you can always get the identifier of any managed object (all "references" are managed, as well as all partial objects and all proxies) without triggering any lazy-loading via: $id = $em->getUnitOfWork()->getEntityIdentifier($object); Hope that helps.
          Hide
          arnaud-lb added a comment -

          Thanks

          > We thought about that but there is always the risk that these methods, for whatever reason, have side-effects and/or access other entity state, in which case lazy-loading is completely bypassed

          Then it would be the responsibility of @NoProxy getters to take care of what they do. Entities already have this kind of responsibility with lazy-loaded references (i.e. some private fields can't be accessed directly by the entity itself).

          Show
          arnaud-lb added a comment - Thanks > We thought about that but there is always the risk that these methods, for whatever reason, have side-effects and/or access other entity state, in which case lazy-loading is completely bypassed Then it would be the responsibility of @NoProxy getters to take care of what they do. Entities already have this kind of responsibility with lazy-loaded references (i.e. some private fields can't be accessed directly by the entity itself).
          Hide
          arnaud-lb added a comment -

          Actually you can even make the proxy getter return the primary key directly

          Show
          arnaud-lb added a comment - Actually you can even make the proxy getter return the primary key directly
          Hide
          Roman S. Borschel added a comment -

          @"Entities already have this kind of responsibility with lazy-loaded references (i.e. some private fields can't be accessed directly by the entity itself)."

          Can you clarify what you mean with that? I am not aware of such a restriction.

          Show
          Roman S. Borschel added a comment - @"Entities already have this kind of responsibility with lazy-loaded references (i.e. some private fields can't be accessed directly by the entity itself)." Can you clarify what you mean with that? I am not aware of such a restriction.
          Hide
          arnaud-lb added a comment -

          I was wrong on this one, there is no such restriction.

          Show
          arnaud-lb added a comment - I was wrong on this one, there is no such restriction.
          Hide
          Benjamin Eberlei added a comment -

          This issue can be solved with the implementation of DDC-522

          Show
          Benjamin Eberlei added a comment - This issue can be solved with the implementation of DDC-522

            People

            • Assignee:
              Roman S. Borschel
              Reporter:
              arnaud-lb
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: