DDC-19: Can't unserialize serialized entity which has a proxy as a single valued relationship as a value #26

New Issue

admin · 2026-01-22T12:24:42+01:00

admin commented

2026-01-22 12:24:42 +01:00

Originally created by @doctrinebot on GitHub (Sep 21, 2009).

Jira issue originally created by user ablock:

namespace Test;
/****
 * @Entity
 */
class Book {
    /**** 
     * @Id @Column(type="integer")
     * @GeneratedValue(strategy="AUTO")
     */
    private $id;

    /****
         * @OneToOne(targetEntity="Author",cascade={"persist"})
         * @JoinColumn(name="author_id", referencedColumnName="id")
         */
    private $author;

    public function setAuthor(Author $a) {
        $this->author = $a;
    }   

    public function getAuthor() {
        return $this->author;
    }
}

/****
 * @Entity
 */
class Author {
    /****
     * @Id @Column(type="integer")
     * @GeneratedValue(strategy="AUTO")
     */
    private $id;

    /****
     * @Column(type="string")
     */
    private $name;

    public function setName($name) {
        $this->name = $name;
    }

    public function getName() {
        return $this->name;
    }
}

include 'entities.php';
include 'config.php';

$query = $em->createQuery('select b from Test\Book b where b.id = 1');
$book = $query->getSingleResult();
$book->getAuthor()->getName(); // If I don't do this, the object is not "loaded" and I can't serialize it.
file*put*contents('out',serialize($book));

include 'entities.php';
include 'config.php';
$b = unserialize(file*get*contents('out'));

This generates the error:

PHP Fatal error:  require(): Failed opening required '/home/ablock/doctrine/lib/Doctrine/Generated/Proxies/Test_AuthorAProxy.php'

Originally created by @doctrinebot on GitHub (Sep 21, 2009). Jira issue originally created by user ablock: ``` namespace Test; /**** * @Entity */ class Book { /**** * @Id @Column(type="integer") * @GeneratedValue(strategy="AUTO") */ private $id; /**** * @OneToOne(targetEntity="Author",cascade={"persist"}) * @JoinColumn(name="author_id", referencedColumnName="id") */ private $author; public function setAuthor(Author $a) { $this->author = $a; } public function getAuthor() { return $this->author; } } /**** * @Entity */ class Author { /**** * @Id @Column(type="integer") * @GeneratedValue(strategy="AUTO") */ private $id; /**** * @Column(type="string") */ private $name; public function setName($name) { $this->name = $name; } public function getName() { return $this->name; } } ``` ``` include 'entities.php'; include 'config.php'; $query = $em->createQuery('select b from Test\Book b where b.id = 1'); $book = $query->getSingleResult(); $book->getAuthor()->getName(); // If I don't do this, the object is not "loaded" and I can't serialize it. file*put*contents('out',serialize($book)); ``` ``` include 'entities.php'; include 'config.php'; $b = unserialize(file*get*contents('out')); ``` This generates the error: ``` PHP Fatal error: require(): Failed opening required '/home/ablock/doctrine/lib/Doctrine/Generated/Proxies/Test_AuthorAProxy.php' ```

admin added the Bug label 2026-01-22 12:24:42 +01:00

admin closed this issue

2026-01-22 12:24:43 +01:00

admin commented

2026-01-22 12:24:44 +01:00

@doctrinebot commented on GitHub (Sep 21, 2009):

Comment created by romanb:

Thanks for reporting this. I think I have an idea what the issue is and will try to address this as soon as possible.

@doctrinebot commented on GitHub (Sep 21, 2009): Comment created by romanb: Thanks for reporting this. I think I have an idea what the issue is and will try to address this as soon as possible.

admin commented

2026-01-22 12:24:45 +01:00

@doctrinebot commented on GitHub (Sep 29, 2009):

Comment created by ablock:

Just looking around, I saw that the generated class names have a ".g" appended to them. When I removed that, it seems to work fine. Is there a reason why this ".g" is in there? If it must be in there, might it be suggested that the class loader takes that into account?

@doctrinebot commented on GitHub (Sep 29, 2009): Comment created by ablock: Just looking around, I saw that the generated class names have a ".g" appended to them. When I removed that, it seems to work fine. Is there a reason why this ".g" is in there? If it must be in there, might it be suggested that the class loader takes that into account?

admin commented

2026-01-22 12:24:45 +01:00

@doctrinebot commented on GitHub (Sep 29, 2009):

Comment created by romanb:

Yea but I would not be very happy with that solution ("g." simply means "generated"). I think it would be much better to be able to completely detach managed objects from doctrine, so that there are no proxies or wrapped collections left. The existing EntityManager#detach() detaches the entity in a way that doctrine does no longer hold any references to it but it still leaves proxies or wrapped collections in place. But I dont want to make detach() remove proxies etc because that is not always wanted and can be unnecessary overhead.

So I'm thinking of a new operation similar to detach but instead of having a cascade option it simply completely detaches a whole connected object graph. All proxies that are already initialized are replaced with the originals and all uninitialized proxies and collections are removed. Afterwards it is completely isolated from doctrine. The big benefit would be that you do not even need doctrine and its proxies around to unserialize them in a different application.

Still thinking about this one. Feel free to speak up if you have ideas or suggestions.

@doctrinebot commented on GitHub (Sep 29, 2009): Comment created by romanb: Yea but I would not be very happy with that solution ("g." simply means "generated"). I think it would be much better to be able to completely detach managed objects from doctrine, so that there are no proxies or wrapped collections left. The existing EntityManager#detach() detaches the entity in a way that doctrine does no longer hold any references to it but it still leaves proxies or wrapped collections in place. But I dont want to make detach() remove proxies etc because that is not always wanted and can be unnecessary overhead. So I'm thinking of a new operation similar to detach but instead of having a cascade option it simply completely detaches a whole connected object graph. All proxies that are already initialized are replaced with the originals and all uninitialized proxies and collections are removed. Afterwards it is completely isolated from doctrine. The big benefit would be that you do not even need doctrine and its proxies around to unserialize them in a different application. Still thinking about this one. Feel free to speak up if you have ideas or suggestions.

admin commented

2026-01-22 12:24:45 +01:00

@doctrinebot commented on GitHub (Sep 29, 2009):

Comment created by romanb:

By the way, did you set "/home/ablock/doctrine/lib" as your cache dir? (Configuration#setCacheDir) ? Because otherwise I cant imagine that to work even without the ".g" suffix.

@doctrinebot commented on GitHub (Sep 29, 2009): Comment created by romanb: By the way, did you set "/home/ablock/doctrine/lib" as your cache dir? (Configuration#setCacheDir) ? Because otherwise I cant imagine that to work even without the ".g" suffix.

admin commented

2026-01-22 12:24:45 +01:00

@doctrinebot commented on GitHub (Sep 29, 2009):

Comment created by romanb:

Maybe we should make both ways possible. Serialization should also work with proxies IMHO, of course with the disadvantage that the proxy classes need to be available to the application that unserializes (no problem if its the same application).

@doctrinebot commented on GitHub (Sep 29, 2009): Comment created by romanb: Maybe we should make both ways possible. Serialization should also work with proxies IMHO, of course with the disadvantage that the proxy classes need to be available to the application that unserializes (no problem if its the same application).

admin commented

2026-01-22 12:24:46 +01:00

@doctrinebot commented on GitHub (Sep 30, 2009):

Comment created by ablock:

Interestingly enough, my cache dir is /tmp...why this works, is a good question, but It definitely works! I definitely agree, that having both options available is good, although some might think it smacks of "YAGNI". Definitely more important that the serialized entities should be "doctrineable", but still a good idea that they should be portable between applications.

@doctrinebot commented on GitHub (Sep 30, 2009): Comment created by ablock: Interestingly enough, my cache dir is /tmp...why this works, is a good question, but It definitely works! I definitely agree, that having both options available is good, although some might think it smacks of "YAGNI". Definitely more important that the serialized entities should be "doctrineable", but still a good idea that they should be portable between applications.

admin commented

2026-01-22 12:24:47 +01:00

@doctrinebot commented on GitHub (Oct 14, 2009):

Comment created by romanb:

This should work better now in HEAD. Please refer to the updated Configuration chapter of the manual, especially the section and configuration options about proxy classes. Also there is a new CLI task to (re)generate proxy classes by hand. Proxy classes now now behave like all other classes with regard to class loading.

@doctrinebot commented on GitHub (Oct 14, 2009): Comment created by romanb: This should work better now in HEAD. Please refer to the updated Configuration chapter of the manual, especially the section and configuration options about proxy classes. Also there is a new CLI task to (re)generate proxy classes by hand. Proxy classes now now behave like all other classes with regard to class loading.

admin commented

2026-01-22 12:24:47 +01:00

@doctrinebot commented on GitHub (Oct 14, 2009):

Issue was closed with resolution "Fixed"

@doctrinebot commented on GitHub (Oct 14, 2009): Issue was closed with resolution "Fixed"

admin referenced this issue

2026-01-22 15:56:00 +01:00

[PR #26] [CLOSED] Ddc 875 #7608

admin referenced this issue

2026-01-22 15:56:00 +01:00

[PR #26] Ddc 875 #7612

Sign in to join this conversation.