Alessandro Siragusa

[clabot:check]

@peterb154 I don't think that I will have the time to do this in the near future. In any case the PR is quite small and resolving the conflicts should...

Yep, it's what I was thinking to do. When I will have some spare time I will work on this feature.

Actually I found a better solution for my problem: during the pre- events I schedule the operations to do and I execute them on the endFlush event. BTW this is...

At this point the cost is negligible, but if the second flush fails my object will be in a dirty state. I can start a new transaction before the flush...

Or I could rename the `flush` method to `unsafeFlush`, the new flush would start a transaction, call `unsafeFlush` and terminate the transaction. In my EventListener I would call then the...

I'm working with the master branch, as the features I PR are only there ATM. The source of the problem is not due to the cleanup in the changeset calculation,...

This is the EventListener I have written: ``` php class SectionConfig implements EventSubscriber { protected $entities = array(); protected $transactions = 0; public function getSubscribedEvents() { return array( 'preFlush', 'prePersist',...

I don't know, but in any case it's a big conceptual mistake. The events must be fired before we begin to persist the documents into the DB.

The only solution that is simple and can work is to do the following: 1. Calculate the changesets 2. Fire the event handlers 3. Calculate once again the changesets 4....