mirror of
https://github.com/doctrine/orm.git
synced 2026-03-24 06:52:09 +01:00
DDC-733: Implement a way of forcing a PersistentCollection to initialize itself #903
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 (Aug 6, 2010).
Originally assigned to: @beberlei on GitHub.
Jira issue originally created by user ccapndave:
Currently the only way to force an uninitialized collection to load itself is to call one of its methods (e.g. ->count()).
Roman suggested something like $em->initialize($collection)
@doctrinebot commented on GitHub (Aug 6, 2010):
@doctrinebot commented on GitHub (Aug 7, 2010):
Comment created by @jwage:
Why not just make the initialize method public on PersistentCollection:
??
@doctrinebot commented on GitHub (Aug 7, 2010):
Comment created by romanb:
Even if that is done, userland code should not use the PersistentCollection API. Remember that a PersistentCollection is supposed to be a transparent wrapper around a Collection implementation. If a user calls $coll->initialize() this code implicitly assumes the concrete type of the collection to be PersistentCollection, which is not a good idea. Userland code should always program to the Collection interface.
@doctrinebot commented on GitHub (Aug 7, 2010):
Comment created by romanb:
Such an initialize method should furthermore handle uninitialized proxies as well as uninitialized collections.
@doctrinebot commented on GitHub (Aug 7, 2010):
Comment created by ccapndave:
For extra points it might be nice if there was an extra cascade option for initialize, and possibly an event hook for pre and post initialize.
@doctrinebot commented on GitHub (Mar 14, 2011):
Comment created by ericmuyser:
I just ran into a bug with this, I believe. I have a Blog which cascade deletes it's Feeds. In cascadeDetach it's saying the count($relatedEntities) is zero for Feeds after the call to unwrap(), even though I know it to be, say, 1 or 2 (output before detaching owner entity). However, if I do ->count() or count($relatedEntities) BEFORE unwrap(), then PersistentCollection by consequence is initialized, and it cascade deletes correctly. If it don't, it actually says the Feeds are still MANAGED after having detached the owner entity. So, yeah, this or some other form of auto-initialization would be useful.
Note: In Blog, I have DQL which fetches Feeds JOINed to Blog, which may be causing the uninitialization (not sure). I'm using EXTRA LAZY LOADING.
@doctrinebot commented on GitHub (Mar 20, 2011):
Comment created by james.harvey:
I have also run into a problem with this: when adding a single entity to an empty collection and then calling flush(), the collection which should now have 1 entity in it actually has 2. I discovered that this can be fixed by calling count() on the collection prior to the flush() operation. I looked into the code and noticed that most methods in PersistentCollection.php (v2.0.3) call $this->initialize() as their first step, but the add() function did not. I think this may be an oversight? By adding $this->initialize() to the add() function my problem was resolved.
@doctrinebot commented on GitHub (Mar 29, 2011):
Comment created by @beberlei:
Hello James, not calling initialize() is a very important performance optimization. Consider your collection containing hundrets, thousands or more entities. You dont want to load them all into memory just to add one new entity.
To solve your problem there is Collection::contains($entity) which will handle your collection correctly. in combination with "EXTRA_LAZY" support introduced in 2.1-DEV this is even very efficient.
@doctrinebot commented on GitHub (Jun 5, 2011):
Comment created by @beberlei:
Implemented $em->getUnitOfWork()->initializeObject().
For this the proxy method load() was turned from private to public and marked as /* @private **/
@doctrinebot commented on GitHub (Jun 5, 2011):
Issue was closed with resolution "Fixed"