-
-
Notifications
You must be signed in to change notification settings - Fork 5.2k
[Messenger] Show how to configure a doctrine transaction middleware #10013
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
It looks great!...but we already mentioned the transaction middleware briefly in https://symfony.com/doc/current/messenger.html#using-middleware-factories where we explain middleware factories. Users are supposed to be able to just use: framework:
messenger:
buses:
command_bus:
middleware:
# Using default entity manager
- doctrine_transaction_middleware
# Using "custom" entity manager
- doctrine_transaction_middleware: ['custom'] |
Oh, I've missed that entire page of documentation! Okey, Lets wait for doctrine/DoctrineBundle#817 |
Now when the doctrine PR is merge, I will update these docs to the new config syntax, right? |
43169a3
to
cc05ed2
Compare
This PR is updated. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me (except these two changes) 👍
Thank you for the review. I've updated the RP |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My instinct is that this should be included in the main doc, but we can figure that out later. I added one real question.
Also, correct me if I'm wrong, isn't this only relevant if you have multiple handlers that are doing flushes? So the transaction would roll back all of them (instead of some working and others not working)? I want it to be clear when a user should definitely use this versus when it won't make any difference for them.
buses: | ||
messenger.bus.command: | ||
middleware: | ||
- validation |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
are we purposely also including validation?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a bit unrelated with the content of this doc indeed, but a good practice, as content of the command in a CQRS application are most of the input by users (on contrary of events which are mostly crafted by developers from already validated data).
No it's relevant even with a single command bus and single handler for the message, so you don't have to deal with flushing changes yourself, nor you can commit changes partially to the database if a command handler failed at some point, rollbacking any change. |
Friendly ping @Nyholm 🎶 👋 Could you please find some time and finish this PR? Thank you 🙏 |
I'm closing this old pull request because we already mention the |
This will fix #9651
This is a first draft. Please add a quick review and after that I'll add code blocks for PHP and XML.
I use the title "Working with doctrine" because I believe we should mention the DispatchAfterCurrentBusMiddleware on this page as well. (Code PR, Doc PR) and the "recording" from entities (Code PR)