DDC-774: Getting the primary key of a reference fetches the object from database #956

Closed
opened 2026-01-22 12:57:12 +01:00 by admin · 9 comments
Owner

Originally created by @doctrinebot on GitHub (Aug 27, 2010).

Jira issue originally created by user arnaud-lb:

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.

Originally created by @doctrinebot on GitHub (Aug 27, 2010). Jira issue originally created by user arnaud-lb: 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.
admin added the Bug label 2026-01-22 12:57:12 +01:00
admin closed this issue 2026-01-22 12:57:13 +01:00
Author
Owner

@doctrinebot commented on GitHub (Aug 27, 2010):

@doctrinebot commented on GitHub (Aug 27, 2010): - relates to [DDC-522: Join columns can not be named the same as the association fields.](http://www.doctrine-project.org/jira/browse/DDC-522)
Author
Owner

@doctrinebot commented on GitHub (Aug 27, 2010):

Comment created by arnaud-lb:

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() {
    }
}
@doctrinebot commented on GitHub (Aug 27, 2010): Comment created by arnaud-lb: 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() { } } ```
Author
Owner

@doctrinebot commented on GitHub (Aug 27, 2010):

Comment created by romanb:

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.

@doctrinebot commented on GitHub (Aug 27, 2010): Comment created by romanb: 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.
Author
Owner

@doctrinebot commented on GitHub (Aug 27, 2010):

Comment created by arnaud-lb:

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

@doctrinebot commented on GitHub (Aug 27, 2010): Comment created by arnaud-lb: 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).
Author
Owner

@doctrinebot commented on GitHub (Aug 27, 2010):

Comment created by arnaud-lb:

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

@doctrinebot commented on GitHub (Aug 27, 2010): Comment created by arnaud-lb: Actually you can even make the proxy getter return the primary key directly ;-)
Author
Owner

@doctrinebot commented on GitHub (Aug 27, 2010):

Comment created by romanb:

@"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.

@doctrinebot commented on GitHub (Aug 27, 2010): Comment created by romanb: @"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.
Author
Owner

@doctrinebot commented on GitHub (Aug 27, 2010):

Comment created by arnaud-lb:

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

@doctrinebot commented on GitHub (Aug 27, 2010): Comment created by arnaud-lb: I was wrong on this one, there is no such restriction.
Author
Owner

@doctrinebot commented on GitHub (Sep 15, 2010):

Comment created by @beberlei:

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

@doctrinebot commented on GitHub (Sep 15, 2010): Comment created by @beberlei: This issue can be solved with the implementation of [DDC-522](http://www.doctrine-project.org/jira/browse/DDC-522)
Author
Owner

@doctrinebot commented on GitHub (Sep 15, 2010):

Issue was closed with resolution "Won't Fix"

@doctrinebot commented on GitHub (Sep 15, 2010): Issue was closed with resolution "Won't Fix"
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: doctrine/archived-orm#956