mirror of
https://github.com/doctrine/orm.git
synced 2026-03-24 06:52:09 +01:00
DDC-80: Allow custom collections #97
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 (Oct 30, 2009).
Jira issue originally created by user dennari:
There should be a configuration option which specifies the class-name of the collection that will be created. The specified collection should implement the \Doctrine\Common\Collections\Collection interface. A custom collection would be needed if one want's to have some sort of aggregate functions, like 'getSum()' or 'getWeight()' for example.
@doctrinebot commented on GitHub (Oct 30, 2009):
@doctrinebot commented on GitHub (Oct 30, 2009):
Comment created by romanb:
You can already use any Collection implementation you like as long as you program to the interface after the entity has become managed (or detached). This is from the manual:
"Collection-valued persistent fields and properties must be defined in terms of the Doctrine\Common\Collections\Collection interface. The collection implementation type may be used by the application to initialize fields or properties before the entity is made persistent. Once the entity becomes managed (or detached), subsequent access must be through the interface type."
The only thing that could probably be enhanced is to instantiate custom collection types when reconstituting entities from the database. But remember, even then you must program to the interface, not the concrete implementation, therefore, what you have in mind might not work. Collection implementations are wrapped in a PersistentCollection during runtime for change-tracking/lazy-load. A PersistentCollection supports the Collection interface only.
I have thought about implementing **call in PersistentCollection to forward unknown method calls to the wrapped instance. However I'm not sure I like that. Doctrine would be unaware of any changes that are made to the collection in those methods, making them rather fragile.
I hope you get the picture :)
@doctrinebot commented on GitHub (May 7, 2010):
Comment created by shurakai:
I'm currently browsing through some open tickets and I think we could mark this one as invalid / won't fix, as the wrapping is a major feature.
@doctrinebot commented on GitHub (Jul 1, 2010):
Comment created by @beberlei:
I think this two go hand in hand, if we do the EXTRA_LAZY stuff we could also do this one here.
@doctrinebot commented on GitHub (Jul 1, 2010):
Comment created by @beberlei:
Ok, slightly modified, you can specifiy which persistent collection implementation you want to use for your entities.
@doctrinebot commented on GitHub (Jan 2, 2011):
Comment created by @beberlei:
This is not necessary anymore with EXTRA_LAZY collections, closing. Allowing to specifiy own collections wouldn't help since most often you also need to touch other parts (UnitOfWork Persisters) so its better for code-maintenance to just not allow this.
@doctrinebot commented on GitHub (Jan 2, 2011):
Issue was closed with resolution "Won't Fix"