[DDC-785] Post-Post-Persist event Created: 02/Sep/10 Updated: 14/Jan/11
|Project:||Doctrine 2 - ORM|
|Reporter:||arnaud-lb||Assignee:||Roman S. Borschel|
postPersist/postUpdate events are triggered in the middle of a unitOfWork, and querying the DB in such events causes infinite loops. Doctrine attempts to flush the entity manager before running any query, which triggers flushing of entities, and postPersist/postUpdate events are triggered again.
I did not checked, but the flush() before each query may be a performance problem too, if doctrine has to determine what has changed, depending on the changetracking policy.
Also, it would be great if postPersist / postUpdate events were triggered after all entities have been persisted. It looks like that entities are flushed by groups of same 'type', and that events for a type are triggered once all of the elements of that group have been flushed, potentially before entities of an other type have been flushed : postPersist / postUpdate events are triggered while some other entities are still not flushed.
|Comment by Benjamin Eberlei [ 03/Sep/10 ]|
That is documented and for perfomance reasons we cannot move the preUpdate/postUpdate/prePersist/postPersist events to other locations inside the UnitOfWork.
There is an onFlush event that allows for more flexibility and is triggered before any update/insert/delete is done by the UnitOfWork.
|Comment by arnaud-lb [ 04/Sep/10 ]|
I understand that. Is there any chance of getting some onPostFlush or similar, which would be triggered like onFlush, but after all update/insert/delete ? Or just some post-something event which is allowed to issue db queries.
|Comment by Gediminas Morkevicius [ 24/Sep/10 ]|
onFlush you can store your entity for furher processing and on postPersist you can check if there are no more insertions and process the entity if it needs additional query
|Comment by Gediminas Morkevicius [ 14/Jan/11 ]|
I think this issue should be closed since the main reason of opening it was the possibility to execute additional queries when inserts were pending in unit of work. In current release it does not cause a flush during an additional query execution anymore.