-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
Only wire ConnectionHelper if it's available #8957
Conversation
Signed-off-by: Alexander M. Turek <me@derrabus.de>
Maybe you figured out a lot of the following already, but in case it helps another reviewer understand this, let's go through it anyway. This area of the code is unfamiliar to me so I did some digging, and found this page of the docs: https://www.doctrine-project.org/projects/doctrine-orm/en/2.9/reference/tools.html#tools
I think projects impacted by this are not Symfony applications, but non-Symfony applications. Users of these applications can still run doctrine commands by using
That would be because it's supposed to be called in a file created by the users, not by Doctrine, as documented in the page above. I think not wiring |
@PowerKiKi @dmaicher can you please advise about this? I think the BC break that might exist would be on commands manually registered by the user (in the config file). The docs say:
|
Fair enough, but the
We don't know if there is code out there that relies on |
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.
No reaction from the others, let's merge this 👍
Thanks @derrabus ! |
I assumed you asked for my inputs because I created #8327 a while ago. My use-case is relatively simple. It is a non-Symfony app (Laminas Mezzio), and I strictly only use commands via |
@PowerKiKi yes, that's why 🙂 I was thinking you would be a relevant reviewer since you are familiar with the binary (I don't use it at all, for instance) |
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.
Sorry I was busy the last days. This change looks good to me 👍
I just tested this PR and can confirm that the following commands still work as expected (after a few minor adjustments). So it's all good 🎉
|
Thanks for checking 🙇 |
DBAL deprecated its
ConnectionHelper
class, a helper for Symfony console applications. I propose to not use that class if it's not there.Part of #8884, #8885.
I haven't found any tests nor usage of the
createHelperSet()
method I've changed here. The other helper that is wired here simply exposes agetEntityManager()
method that… well… returns an entity manager. In modern Symfony applications, we would probably use DI to make the EM available to commands. I feel like we should follow the example of DBAL here and deprecatecreateHelperSet()
,EntityManagerHelper
and related classes and change our own commands to use DI instead. That could be done in a follow-up PR. WDYT?