Doctrine 2 - ORM

Post-Post-Persist event

Details

  • Type: Improvement Improvement
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 2.0-BETA4
  • Fix Version/s: None
  • Component/s: ORM
  • Security Level: All
  • Labels:
    None

Description

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.

Activity

Descending order - Click to sort in ascending order
Hide
Permalink
Gediminas Morkevicius added a comment -

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.

Show
Gediminas Morkevicius added a comment - 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.
Hide
Permalink
Gediminas Morkevicius added a comment -

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
I have faced all these issues and you can check http://github.com/l3pp4rd/DoctrineExtensions/tree/master/lib/DoctrineExtensions/Translatable/
for a solution to your problem

Show
Gediminas Morkevicius added a comment - 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 I have faced all these issues and you can check http://github.com/l3pp4rd/DoctrineExtensions/tree/master/lib/DoctrineExtensions/Translatable/ for a solution to your problem
Hide
Permalink
arnaud-lb added a comment -

Thanks.

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.

Show
arnaud-lb added a comment - Thanks. 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.
Hide
Permalink
Benjamin Eberlei added a comment -

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.

Show
Benjamin Eberlei added a comment - 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.

People

  • Assignee:
    Roman S. Borschel
    Reporter:
    arnaud-lb
Vote (0)
Watch (1)

Dates

  • Created:
    Updated: