mirror of
https://github.com/doctrine/orm.git
synced 2026-03-23 22:42:18 +01:00
Doctrine\Common\Collections\ArrayCollection::set(): Argument #1 ($key) must be of type string|int, null given, called in /path/to/project/vendor/doctrine/orm/src/PersistentCollection.php on line 162 #7461
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @savemetenminutes on GitHub (Jan 15, 2025).
Bug Report
Summary
A regression was introduced by this commit:
439b4dacf4/#diff-ecc4306d602db732bf06eda6ac0fc41b23fe8a25f4a2548196f813f30dd2ac35R1277$childEntity->getParent()so that it goes throughvendor/doctrine/orm/src/Proxy/ProxyFactory.php:279$entityPersister = $this->uow->getEntityPersister($className);$this->filterHashof the BasicEntityPersister$parentEntity->getChildCollection()so that it goes throughvendor/doctrine/orm/src/UnitOfWork.php:2702$persister = $this->getEntityPersister($assoc->targetEntity);->currentPersisterContext->rsminstance of ResultSetMapping by calling the->addFieldResulttwice for each ChildEntity column. So theResultSetMapping->fieldMappingsarray in the end will hold each entity column twice, but with different alias (index). The\Doctrine\ORM\Persisters\Entity\BasicEntityPersister::getSelectColumnsSQL()mechanism for detecting whether the current instance has already calculated the select columns from a previous queryvendor/doctrine/orm/src/Persisters/Entity/BasicEntityPersister.php:1234if ($this->currentPersisterContext->selectColumnListSql !== null && $this->filterHash === $this->em->getFilters()->getHash()) {is bypassed due to the new filter hash, but the
->currentPersisterContext->sqlAliasCounteris not reset andvendor/doctrine/orm/src/Persisters/Entity/BasicEntityPersister.php:1243$columnList[] = $this->getSelectColumnSQL($field, $this->class);will result in
\Doctrine\ORM\Persisters\Entity\BasicEntityPersister::getSQLColumnAlias()to keep incrementing the
$this->currentPersisterContext->sqlAliasCounter++from the position it was left at from the previous query, thus the second column set with the greater alias indexes will eventually be fetched in the result row. Due to the entity persister's ResultSetMapping instance's
->indexByMappointing to the alias with the lesser index the following happens:vendor/doctrine/orm/src/Internal/Hydration/ObjectHydrator.php:498$resultKey = $row[$this->resultSetMapping()->indexByMap[$dqlAlias]];Here
$resultKeybecomes null and$this->hints['collection']->hydrateSet($resultKey, $element);in turn calls
vendor/doctrine/orm/src/PersistentCollection.php:162$this->unwrap()->set($key, $element);resulting in the exception from the title of the issue.
Current behavior
An exception is thrown.
Expected behavior
Collection indexing used to work in this case in version 3.3.0 of
doctrine/ormHow to reproduce
Providing partial stack traces of the two fetches within the same UnitOfWork - with the breakpoint set at the problematic double addition of the columns in the
ResultSetMapping->fieldMappings.And a JSON formatted partial stack trace of the Exception:
@greg0ire commented on GitHub (Jan 16, 2025):
cc @dbannik
@savemetenminutes commented on GitHub (Apr 3, 2025):
Is @dbannik an active contributor or just did a one time patch for his use case? It's been 3 months now.
@dbannik commented on GitHub (Apr 7, 2025):
@savemetenminutes Could you please provide some code to reproduce this error?
@savemetenminutes commented on GitHub (Apr 9, 2025):
@dbannik
@dbannik commented on GitHub (Apr 10, 2025):
@savemetenminutes I couldn't reproduce the error
DIFF: 4340fe243eff0259f17b8c964bf70c5febd34233
Executed sql in test
@savemetenminutes commented on GitHub (Apr 10, 2025):
@dbannik I don't see the
index-by="id"on the one-to-many relation. All relations should be lazy fetched.@dbannik commented on GitHub (Apr 11, 2025):
18b8ea7fc1@savemetenminutes did not change the situation. Provide a test that will not pass on your problem!
@savemetenminutes commented on GitHub (Apr 13, 2025):
@dbannik someone has fixed your regression in 3.3.2 in this commit:
6755bb0c7bIn the future please pay attention to the description of the issues! I have provided more than enough information on the the issue, how to reproduce it and the circumstances around it, including the version, which introduces this issue:
@dbannik commented on GitHub (Apr 13, 2025):
I'm glad that everything has been fixed for you
From now on, check the latest versions of the package for errors, as they may have already been fixed by other project contributions!
@savemetenminutes commented on GitHub (Apr 14, 2025):
I'm sure that eventually, after enough time has passed, they will...