mirror of
https://github.com/doctrine/orm.git
synced 2026-03-23 22:42:18 +01:00
DDC-418: Doctrine\ORM\Query should return ArrayCollection instead of raw arrays #522
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 @doctrinebot on GitHub (Mar 12, 2010).
Jira issue originally created by user @guilhermeblanco:
The inclusion of Collection support in Doctrine leads to a REALLY nice support.
However, ->getResult() doesn't return an ArrayCollection instance.
This should be valid only for getResult, since it doesn't sound correct to return this instance in other situations (->getArrayResult(), ->getScalarResult(), ->getSingleResult(), ->getSingleScalarResult())
Cheers,
@doctrinebot commented on GitHub (Mar 12, 2010):
Comment created by @beberlei:
this is not a good idea, array collection only makes sense in the context of a relation between two entities not as a result for a query.
@doctrinebot commented on GitHub (Mar 12, 2010):
Comment created by @guilhermeblanco:
First note: PHP really need Collection support...
Anyway, one good example is convert a collection into JSON format.
I always wondered how hard it is to have a Jsonable interface in PHP that json_encode/decode can use to compress/decompress instances of them (like Serializable).
If we get this (some discussion is already on schedule), we could make a simple:
json_encode($q->getResult());
And it would work...
Ok, I may be dreaming... but PHP lacks in so many places, but we should never lose hope!
Cheers,
@doctrinebot commented on GitHub (Mar 12, 2010):
Comment created by romanb:
This is intentional. An array is simpler, cheaper and also more flexible as you can use all of phps array operations on it.
@doctrinebot commented on GitHub (Mar 12, 2010):
Issue was closed with resolution "Won't Fix"
@doctrinebot commented on GitHub (Mar 12, 2010):
Comment created by romanb:
As a side note, we always try to be idiomatic. This means if possible, we always use something "native". The custom collections for domain objects are an unfortunate need because we cant "instrument" plain php arrays but where possible we should use normal arrays. This is another such case.
@doctrinebot commented on GitHub (Mar 12, 2010):
Comment created by romanb:
And I absolutely agree with Guilherme on the PHP collections issue. While all the special SPL data structures are nice, a basic SplArray interface + default implementation would be ideal for us and the users. Then users can type-hint and use SplArray and PersistentCollection simply implements that interface. Anyone wants to push such an initiative to internals? ;)