Doctrine Project

[DDC-2338] Entity with composite foreign keys identifiers should be persisted after related entities without exception

Thu, 7 Mar 2013 09:40:20 +0000

I've seen that when you create an entity with a composite foreign key as identifier it cannot be flushed until the related entities are already flushed to the database and not just persisted.

It would be nice to let the user flush all the entities together and just INSERT first the related entities to get the ID and then use that to INSERT the entity with composite foreign keys.

I'm going to create a pull request with the failing test.

[DDC-2317] [UnitOfWork] Entity in identityMap but not present in entityIdentifiers

Tue, 26 Feb 2013 08:35:23 +0000

I'm using symfony 2.1.8 and sonata/admin-bundle
I have a quite complex entity mapping.

A Competence has many CompetenceAction (superclass)
CompetenceActionBuff is a subclass of CompetenceAction and has exactly one buff (selectable in the form by an 'entity' field).

When i want to edit a Competence, i have the following error message about the Buff entity linked to the CompetenceActionBuff:
"Entities passed to the choice field must be managed. [...]"
The exception is raised in Symfony/Bridge/Doctrine/Form/ChoiceList/EntityChoiceList.php at line 412

I've added some debug code in the EntityManager::contains() method and it shows that my entity is in the entityMap but his oid is not in the keys of entityIdentifiers making the call to UnitOfWork::isInIdentityMap() return false at line 1505.

When submitting the form, there is no problems. All the entities are correctly created in the database. The exception is thrown only when i want to edit the Competence object. Saying that the Buff object is not managed when it was first loaded from the database... strange, no?

Finally, i tried to comment the test

if (!$this->em->contains($entity)))

in EntityChoiceList::getIdentifierValues() and everything seemed to work properly.

[DDC-2306] Lazy loading associated entity's property causes identity loss when another association is set to fetch="EAGER"

Tue, 26 Feb 2013 08:27:25 +0000

There appears to be a bug in UnitOfWork.php, introduced in Merge pull request #406 from Ocramius/DCOM-96. The relevant section is lines 2479-2495.

In the attached test sandbox, there are 4 entities.

User and Address have a many-many relationship via UserAddress – this more or less duplicates what I have in my actual application. There is another entity that both User and Address refer to in a one-to-many relationship – Zone.

When the Zone relationship on User and Address is set to fetch="LAZY", the problem is absent. When the relationship is set to fetch="EAGER", the problem manifests as such:

When I load a User via $em->find(), and then access properties on a related Address, the identity of the Address is lost. The same is true going in the other direction. I var_dump the Address before accessing its street property, and it shows up properly as an uninitialized proxy with just the id set. After I access the street property of the Address, var_dump shows the proxy is loaded and initialized, with all properties set except the identity, which is now null.

I stepped through the code using XDebug, and found that the referenced lines in UnitOfWork.php are setting the created Address entity's properties incorrectly, removing the identity from the generated entity. It seems to have something to do with the _hints parameter.

I'm not sure what the fix is, because I am not familiar enough with this part of the code and what it is intended to do. I assume that this is not intended behavior.

I've included my test case sandbox, which references ../../../../autoload.php to load Doctrine. This was tested against doctrine2/master as of today.

[DDC-2219] computeChangeSets array_merging for associationMappings problem ?

Mon, 7 Jan 2013 08:52:53 +0000

Is this normal that when i call "$changeset = $unitOfWork->getEntityChangeSet($myObject);", it only return changes of root Object, all changes in sub collection (OneToMany) are less (not merging in the changeset) ?

Is there an issue for that?

[DDC-2179] Transactions should sent in group not chunked

Fri, 30 Nov 2012 14:31:16 +0000

In UnitOfWork::commit() it seems that a transaction is done like this:

will send separate queries for transaction start
compute the queries/send them to the db driver
execute the commit statement
optionally execute rollback

The question would be, should my webserver have some issues with resources, wouldn't this part of the code be a pain for the DB?

I don't know how mysql, for example, handles sending the transaction in chunks as opposed to sending it in 2/3 statements ( begin + ops and commit / + revert in case of failure) or in mySQL,l the transaction is evaluated on COMMIT statement only?

If my assumption about how MySQL works, locking everything as soon as the statement is on the server, then shouldn't Doctrine use a internal buffer for sending transactions to the DB driver in order to avoid all sorts of problems that appear in high concurency scenarios?

Best regards.

[DDC-2176] Illegal offset type in isset or empty in UnitOfWork

Wed, 1 May 2013 21:20:26 +0000

Steps to reproduce the problem?

A custom DBAL type, that extends a scalar build-in type e.g. DBAL\Types\StringType

convertToPHPValue of custom DBAL type returns an instance of a class (implements __toString method)

Custom DBAL type is used as primary key in an entity

initially persist entity and flush entity manager

modify entity (keep same primary key) and persist entity again causes:

Warning: Illegal offset type in isset or empty in vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php line 2407

I guess the solution in Doctrine\ORM\Internal\Hydration namespace by explicit converting result of convertToPHPValue if result is not a scalar value.

[DDC-2086] [GH-484] Prevented "Undefined index" notice when updating

Fri, 9 Nov 2012 21:10:25 +0000

This issue is created automatically through a Github pull request on behalf of jappie:

Url: https://github.com/doctrine/doctrine2/pull/484

Message:

While executing updates on an entity scheduled for update without a change-set, an "Undefined index" notice is raised.

This issue will occur when you manually call $em()->getUnitOfWork()->scheduleForUpdate() on an entity that hasn't changed. The entity will be included in UnitOfWork::$entityUpdates, but because there are no changes, its oid will not be included in UnitOfWork::$entityChangeSets.

I know I'm misusing scheduleForUpdate() a bit in this case, but the notice can easily be prevented with a !empty().