postFlush event implementation

[dfreudenberger]

No description provided.

[jwage]

👍

[beberlei]

Can you move this behind the snapshot taking?

[Isinlor]

I have question regarding this implementation. I’m trying to implement notification system based on doctrine events. I want to add my notifications on postFlush based on previous events. However I’m struggling to understand why postFlush is dispatched before clearing up https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/UnitOfWork.php#L427 ? Do you know maybe?

It seems like other people have similar problem: http://stackoverflow.com/questions/10374155/doctrine-inserting-in-postpersist-event

For me it seems like a bug, but even documentation claims this is how it should be:

EntityManager#flush() can NOT be called safely inside its listeners.
http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/events.html#postflush

Do you think that it could be a good idea to add "safePostFlush" event? I can take care about making pull-request.

[DHager]

@Isinlor I think it's worth pondering whether the use-case for "trigger more persisting" is one that Doctrine should be responsible for and support... Versus business-logic stuff which should be handled by whatever framework is using Doctrine.

[Isinlor]

@DHager Indeed, mixing doctrine listeners and business logic seems not right, but I think there are two reasons for this use case to be valid:

1. Doctrine is very often the single point of communication with the database
2. Doctrine delay actual database update until flush

For example I want to trigger event that will add notification after certain changes happens in an entity.
Doctrine is the single point of communication with database in my application and this makes doctrine listeners useful for making sure that certain things happens always when the data is updated.

Moreover after the change is saved in the database I want doctrine listener to trigger domain specific event and I want listeners of this event to be sure that the change will be actually saved in the database.

I could try to make sure that notification is always added when change happens by triggering domain specific event in an entity. Unfortunately this lead to a problem with being sure that the change was saved.

I don't want to trigger manually, after flush, every event that could happen in all places in my application. There maybe to many possible combinations overall and it may be to hard to keep track of them. Doctrine could do this perfectly fine for me.

I could go with this solution: http://stackoverflow.com/a/11054101/893222 but this forces me to act on an event that is not related to the persistence itself and therefore may not occur eg. kernel.response event may not be triggered in command line.

[DHager]

Unfortunately this lead to a problem with being sure that the change was saved.

FWIW, my current big project does this with a system of domain-objects with its own (custom, separate from Doctrine) style of events/listeners, and its whole swarm of behavior operates inside a callback passed to EntityManager::transactional() .

This way my business-logic doesn't know anything about persistence or flushing, it only knows that whatever complicated gymnastics of changes and counter-changes it does are going to succeed (or fail) as a group. It changes the style from "Reacting to what Doctrine decides" into "Proactively telling Doctrine what to save."