How does that even make sense? By nature SQL results are iterative. No matter what hydration (object, array, scalar) is done, the result is first and foremost iterable. Only exception is for joined entities.
So I just don't understand how scalars (which are not even tracked by Doctrine for anything) could cause a problem.

With what has been said. I will allow myself a few assumptions. ArrayHydrator can just return an array, so there is no reason to have any problem with tracking or keeping results in memory. Same goes for ScalarHydrator. SingleScalarHydrator does not apply in an iterable context. So, we are left with SimpleObjectHydrator and ObjectHydrator. Logicaly, I'd assume the latter to be a more general solution that the former. Skimming the code, this all seems true. So we are left with ObjectHydrator.

Reading more code... We see ObjectHydrator is the only one with an actual ::cleanupAfterRowIteration(). So there is no reason to prevent any other Hydrator from working with mixed result sets... Well, only ArrayHydrator would be useful in an iterable mixed result set, but outright denying it is a problem.

ObjectHydrator... Well first and foremost, ::cleanupAfterRowIteration() does not fix keeping the result set in memory by itself. UoW also keeps it in memory once hydrated and require a manual clear to work. Nothing in the concepts of an ObjectHydrator means no mixed results allowed. This limit feels like contrived logic in need of a refactor. It is not the only bug plaguing hydration: #8099, #8280, #8394 and #8442.

TL:DR

There is no reason to disallow mixed results iteration for any sensible hydrator beside ObjectHydrator.
The above limitations seems to be due to contrived code rather than an actual limit on how Doctrine works. Refactoring hydrator internals could be a better solution.

Query::toIterable() should support mixed result queries with scalar mappings #8520

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions