Mock_ParserResult_*::getParameterMappings() was returning null, which
was then passed to count() on Query.php:308, causing a "Parameter must
be an array or an object that implements Countable" error.
It fail now. In `XmlDriver::_parseOptions` we need somehow to maintain
a list of options, that are supposed to be boolean, and then call
`$this->evaluateBoolean()` on them.
When merging an entity with a to-many association, it will store the
original entity data using the object hash of the to-be-merged entity
instead of the managed entity. Since this to-be-merged entity is not
managed by Doctrine, it can disappear from the memory. A new object
can reuse the same memory location and thus have the same object hash.
When one tries to persist this object as new, Doctrine will refuse it
because it thinks that the entity is managed+dirty.
This patch is a very naive fix: it just disables storing the original
entity data in case of to-many associations. It may not be the ideal
or even a good solution at all, but it solves the problem of object
hash reuse.
The test case relies on the immediate reusing of memory locations by
PHP. The variable $user has twice the same object hash, though referring
a different object. Tested on PHP 5.6.17
Without the fix, the test fails on the last line with:
A managed+dirty entity Doctrine\Tests\Models\CMS\CmsUser@[...] can not
be scheduled for insertion.
DebugStack starts queries array from index 1 rather than 0 so the last query was never printed.
Also array params caused an 'Array to string conversion' error
Background:
Test relied on an `A->B->C` association:
* `A#id` being `B`
* `B#id` being `C`
* `C#id` being an auto-generated identifier (post-insert)
This cannot work, because it breaks the UnitOfWork's identity map.
Specifically, no entries for `A` and `B` can exist in the identity map until `C` entries
are persisted (post-insert).
That means that the identifier generator for `A` and `B` should not be an "assigned"
generator, but should instead be a post-insert generator waiting for other entities
to be persisted.
We cannot fix this in ORM 2.x, but we'll need to invent something for 3.x in order to
fix that (directed graph, or caching the order of operations in the metadata graph).
The `ClassMetadataInfo` was always using the "current class" to
fetch the reflection of a property even when a field is declared
on the parent class (which causes `ReflectionProperty` to throw
an exception).
