DDC-675: EntityManager->find() returns detached (or otherwise unmanaged) object. #831

New Issue

admin · 2026-01-22T12:52:04+01:00

admin commented

2026-01-22 12:52:04 +01:00

Originally created by @doctrinebot on GitHub (Jul 9, 2010).

Jira issue originally created by user napsi:

The find method seems to be broken. Returned objects are not managed according to the EntityManager. Fetching the same object via findAll() works.

$e = $em->find('\net\jay\products\doctrine\ProductEntityType', 1);
print "Class: " . get_class($e) . "<br>";
print "Contained: " . ($em->contains($e) === true ? 'Yes' : 'No');

This gives me:

Class: net\jay\products\doctrine\ProductEntityType
Contained: No

Originally created by @doctrinebot on GitHub (Jul 9, 2010). Jira issue originally created by user napsi: The find method seems to be broken. Returned objects are not managed according to the EntityManager. Fetching the same object via findAll() works. ``` $e = $em->find('\net\jay\products\doctrine\ProductEntityType', 1); print "Class: " . get_class($e) . "<br>"; print "Contained: " . ($em->contains($e) === true ? 'Yes' : 'No'); ``` This gives me: Class: net\jay\products\doctrine\ProductEntityType Contained: No

admin added the Bug label 2026-01-22 12:52:04 +01:00

admin closed this issue

2026-01-22 12:52:04 +01:00

admin commented

2026-01-22 12:52:06 +01:00

@doctrinebot commented on GitHub (Jul 9, 2010):

Comment created by @beberlei:

can you try to build a reproducible test-case? This would be a serious issue, however we cannot reproduce it this way.

@doctrinebot commented on GitHub (Jul 9, 2010): Comment created by @beberlei: can you try to build a reproducible test-case? This would be a serious issue, however we cannot reproduce it this way.

admin commented

2026-01-22 12:52:08 +01:00

@doctrinebot commented on GitHub (Jul 9, 2010):

Comment created by napsi:

Ah it turns out to be the leading namespace \ in the find parameter that killed me. Without it, the object turns out managed.

Slightly troublesome that the object is returned in both cases perhaps.

I tested with this added to tests/Doctrine/Tests/ORM/Functional/BasicFunctionalTest.php, in case the behaviour needs to be changed:

public function testFind()
    {
        // Create
        $user = new CmsUser;
        $user->name = 'Roman';
        $user->username = 'romanb';
        $user->status = 'developer';
        $this->_em->persist($user);

        $this->_em->flush();

        // Find1
        $this->_em->clear();
        $user2 = $this->_em->find('Doctrine\Tests\Models\CMS\CmsUser', $user->id);
        $this->assertTrue($this->_em->contains($user2));

        // Find2
        $this->_em->clear();
        $user3 = $this->_em->find('\Doctrine\Tests\Models\CMS\CmsUser', $user->id);
        $this->assertTrue($this->_em->contains($user3));
    }

Find1 passes, while Find2 fails. The user is found in both cases though.

Have a nice weekend. :)

@doctrinebot commented on GitHub (Jul 9, 2010): Comment created by napsi: Ah it turns out to be the leading namespace \ in the find parameter that killed me. Without it, the object turns out managed. Slightly troublesome that the object is returned in both cases perhaps. I tested with this added to tests/Doctrine/Tests/ORM/Functional/BasicFunctionalTest.php, in case the behaviour needs to be changed: ``` public function testFind() { // Create $user = new CmsUser; $user->name = 'Roman'; $user->username = 'romanb'; $user->status = 'developer'; $this->_em->persist($user); $this->_em->flush(); // Find1 $this->_em->clear(); $user2 = $this->_em->find('Doctrine\Tests\Models\CMS\CmsUser', $user->id); $this->assertTrue($this->_em->contains($user2)); // Find2 $this->_em->clear(); $user3 = $this->_em->find('\Doctrine\Tests\Models\CMS\CmsUser', $user->id); $this->assertTrue($this->_em->contains($user3)); } ``` Find1 passes, while Find2 fails. The user is found in both cases though. Have a nice weekend. :)

admin commented

2026-01-22 12:52:08 +01:00

@doctrinebot commented on GitHub (Jul 9, 2010):

Comment created by romanb:

That is because the objects are stored in the identity map based on their class name. We could strip off leading backslashes but once we start doing that we will always miss some places. Class names in strings are always fully-qualified, thus there is never a need to use a leading backslash in a string that contains a class name. The leading backslash is only useful in actual code, not in strings.

@doctrinebot commented on GitHub (Jul 9, 2010): Comment created by romanb: That is because the objects are stored in the identity map based on their class name. We could strip off leading backslashes but once we start doing that we will always miss some places. Class names in strings are **always fully-qualified**, thus there is never a need to use a leading backslash in a string that contains a class name. The leading backslash is only useful in actual code, not in strings.

admin commented

2026-01-22 12:52:09 +01:00

@doctrinebot commented on GitHub (Jul 9, 2010):

Comment created by napsi:

Maybe just mentioning it in a "common use errors" section of the manual could be a good solution to avoid too much despair when the \ is added by mistake. If it's not already mentioned in there somewhere.

@doctrinebot commented on GitHub (Jul 9, 2010): Comment created by napsi: Maybe just mentioning it in a "common use errors" section of the manual could be a good solution to avoid too much despair when the \ is added by mistake. If it's not already mentioned in there somewhere.

admin commented

2026-01-22 12:52:10 +01:00

@doctrinebot commented on GitHub (Jul 20, 2010):

Comment created by obrys:

The solution is just add a warning when leading \ is found.

The same bug happends to me. It took lots of hours to find that it was by .

Thanks
obrys

@doctrinebot commented on GitHub (Jul 20, 2010): Comment created by obrys: The solution is just add a warning when leading \ is found. The same bug happends to me. It took lots of hours to find that it was by . Thanks obrys

admin commented

2026-01-22 12:52:10 +01:00

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

Comment created by romanb:

Fixed.

@doctrinebot commented on GitHub (Aug 8, 2010): Comment created by romanb: Fixed.

admin commented

2026-01-22 12:52:11 +01:00

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

Issue was closed with resolution "Fixed"

@doctrinebot commented on GitHub (Aug 8, 2010): Issue was closed with resolution "Fixed"

admin referenced this issue