Orm: In UnitOfWork.commit() why postFlush event is dispatched just before cleanup not after?

Created on 16 Feb 2017  Â·  2Comments  Â·  Source: doctrine/orm

Hello,
I'm curious why this line: https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/UnitOfWork.php#L415
is just before internal data clear up and not after?
If it would be after clear up we would be able to call flush() inside postFlush handlers, but now docs http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/events.html#postflush don't allow that.
Is that any deeper technical reason for that restriction?
Just now we are forced to do some workarounds like attaching to "kernel.terminate" and reflush pending (created inside preupdate/prepersist) entities there.

Most helpful comment

E.g. global entity changes logger, we collect everything in preupdate,
prepersist and newly created entities are stored inside pendingEntity, so
when we should persist and flush these? Now we are doing it in
kernel.terminate, but I think postflush would be better if event would be
triggered after full clear up. I think it's conceptually same like a
seperate UoW.

Shortly a problem is that during UoW commit some services will generate new
entities which must be persisted/flushed after previous UoW commit.

On Feb 16, 2017 11:11 PM, "Marco Pivetta" notifications@github.com wrote:

If it would be after clear up we would be able to call flush() inside
postFlush handlers

It is never a good idea to call flush() from any listeners, as it's just
going to cause recursion and likely further unwanted (heavy) performance
issues.

Flushing a completely separate UoW is probably better in this scenario.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/doctrine/doctrine2/issues/6292#issuecomment-280461915,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEAcnLE2qnqoF4OZaIGzH9my6e8uMZq-ks5rdLuPgaJpZM4MDgxq
.

All 2 comments

If it would be after clear up we would be able to call flush() inside postFlush handlers

It is never a good idea to call flush() from any listeners, as it's just going to cause recursion and likely further unwanted (heavy) performance issues (if not infinite recursion, since managing UoW state is quite complex)

Flushing a completely separate UoW is probably better in this scenario.

E.g. global entity changes logger, we collect everything in preupdate,
prepersist and newly created entities are stored inside pendingEntity, so
when we should persist and flush these? Now we are doing it in
kernel.terminate, but I think postflush would be better if event would be
triggered after full clear up. I think it's conceptually same like a
seperate UoW.

Shortly a problem is that during UoW commit some services will generate new
entities which must be persisted/flushed after previous UoW commit.

On Feb 16, 2017 11:11 PM, "Marco Pivetta" notifications@github.com wrote:

If it would be after clear up we would be able to call flush() inside
postFlush handlers

It is never a good idea to call flush() from any listeners, as it's just
going to cause recursion and likely further unwanted (heavy) performance
issues.

Flushing a completely separate UoW is probably better in this scenario.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/doctrine/doctrine2/issues/6292#issuecomment-280461915,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEAcnLE2qnqoF4OZaIGzH9my6e8uMZq-ks5rdLuPgaJpZM4MDgxq
.

Was this page helpful?
0 / 5 - 0 ratings