TYPO3 Core

Hi community

as written in the subject, the DataMapper does not respond to changing the implementing class when looking up objects in it's persistence session.

Inside the DataMapper::mapSingleRow

if ($this->identityMap->hasIdentifier($row['uid'], $className)) {
    $object = $this->identityMap->getObjectByIdentifier($row['uid'], $className);
} else {
    $object = $this->createEmptyObject($className);
    $this->identityMap->registerObject($object, $row['uid']);
    $this->thawProperties($object, $row);
    $object->_memorizeCleanState();
    $this->persistenceSession->registerReconstitutedEntity($object);
}
return $object;

The hasIdentifier check verifies (ultimately against the persistence session) if the object already has been reconstituted in this session. It uses the $className that was actually supplied. However, during createEmptyObject, the Object Container actually checks if the $className has a different implementing class (set by e.g. by using config.tx_extbase.objects).

Container::getEmptyObject

$className = $this->getImplementationClassName($className);

This means that the resulting object can be different than the class used to look up if said object is already part of the persistence session. In effect, this means the "_hasIdentifier_" check will always return FALSE when checking a $className that has a different implementing class.

This leads to unnecessary reconstitution of objects that are already part of the session. Furthermore, it leads to object reference problems as e.g. a repository will return the same instance of an object when it's implementation hasn't been overwritten, but it will return two different instances of the object when it has. This is very hard to catch when using "===" operations to check for object equality, which is done e.g. by some versions of Powermail.

This issue was found in TYPO3 Version 6.2; looking at the current 7.2 branch it looks like it's present there as well, though.

Cheers
Erik