Custom post commit event

[ro0NL]

Hi,

What's the best approach migrating from deprecated onTransactionCommit?

The connection will not have an event manager anymore

The built-in entity manager calls Connection::commit in several places.

[derrabus]

Create a middleware and decorate the Connection::commit() method.

[ro0NL]

im researching that, but i dont find a way to get the event manager bound to that connection

only DBAL\Connection receives the event manager, not Driver\Connection AFAIK

[ro0NL]

https://www.doctrine-project.org/projects/doctrine-dbal/en/3.7/reference/configuration.html#wrapper-class 👀

[ro0NL]

please dont deprecate it :D

[derrabus]

im researching that, but i dont find a way to get the event manager bound to that connection

Because DBAL won't have events anymore, it won't have an event manager either. The middleware system is the replacement. And no, you don't need a custom wrapper class. Implement a middleware. I'm using the word middleware a couple of times more so you don't get distracted by other extension points. You want a middleware. Middleware. Really.

[ro0NL]

only DBAL\Connection receives the event manager, not Driver\Connection AFAIK

https://github.com/doctrine/dbal/blob/5b7bd66c9ff58c04c5474ab85edce442f8081cb2/src/DriverManager.php#L186-L197

[ro0NL]

ok. i could dispatch my own framework/symfony event, and refactor the listeners instead.

It's probably the better approach.

[ro0NL]

yes you did

in case it wasnt obvious i was hoping to reuse DOCTRINE's event manager with existing listeners.

you didnt tell me how to do that using "middlewares"

[derrabus]

i was hoping to reuse DOCTRINE's event manager

And I am here to destroy your hopes and tell you to let go.

DBAL does not emit events anymore. A middleware is the proper replacement for such a listener.

• Take one of your listeners.
• Turn it into a middleware.
• Repeat until all of your listeners are migrated.
• Forget the event manager has ever existed in the DBAL.

Of course, you can do anything you want inside a middleware, even trigger events, but why the hell would you want to do that?

[ro0NL]

i cant just migrate all doctrine event listeners to middlewares, they are entity listeners in fact 😅

ideally the onTransactionCommit event was implemented to the entity manager i guess

And I am here to destroy your hopes and tell you to let go.

not so soon :) there's still an doctrine event manager available, and i wish i could use it to dispatch previous commit event with it

[derrabus]

there's still an doctrine event manager available, and i wish i could use it to dispatch previous commit event with it

Yes, you can dispatch your own events, but why would you do that? DBAL 3 continues to emit the events. It's deprecated to listen to them, but if you need time to migrate to middleware, there's nothing wrong with consuming the old events for the time being.

[ro0NL]

our whole business relies on doctrine entity events and thus listeners, we cant just get rid of it

im seeking compatibility, any dispatcher is fine

but the compatibility between Dbal\Connection and Driver\Connection is a bit poor (i need to know the current transaction level)

[ro0NL]

the current transaction level is also only available in Dbal\Connection, not Driver\Connection

so all in all, wrapperClass seems the best approach to get all info and dispatch events