-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[DoctrineBridge] always load event listeners lazy via ServiceLocator #27675
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
I really think there is no downside - this pattern is followed in many other places in Symfony. The lazy flag was added SO long ago, I think it was basically an old work around before we had the proper service locator solution. I’d say, move forward with the deprecation and upgrade log stuff. Then we’ll probably need Nicolas to double check the implementation (it makes sense to me - but this is his area). And thanks for making a PR - what an awesome surprise! |
deprecation notice for the |
@weaverryan @chalasr but technically I removed the usage of the flag already 😄 So is a deprecation still correct? It should say something like Or should we keep using the flag and remove it completely in 5.0? Although I think it does not have any BC breaks. Unless someone is weirdly relying on the fact that a service is eagerly instantiated 😋 |
I think going always lazy now is fine, the deprecation notice would only allow people to remove a dead tag attribute, and stop being triggered in 5.0. Not sure we had a similar case in the past so having an additional opinion would be good |
...ridge/Doctrine/DependencyInjection/CompilerPass/RegisterEventListenersAndSubscribersPass.php
Outdated
Show resolved
Hide resolved
By not triggering any depreciation for the unused "lazy" attribute, we're making it easier for e.g. bundles to support several major versions, isn't it? So should stay as is then IMHO. |
@nicolas-grekas haha ok. I just added the deprecation 😄 But I can remove it again if needed. No problem. |
So, would we keep that lazy flag (after it does nothing) forever? You’re right about compat, but keeping it forever seems odd. |
We should just ignore it. |
Documentation PR added, deprecation notice removed, tested with a real Symfony app. Ready for a last round of reviews 😊 |
Thank you @dmaicher. |
…ServiceLocator (dmaicher) This PR was squashed before being merged into the 4.2-dev branch (closes #27675). Discussion ---------- [DoctrineBridge] always load event listeners lazy via ServiceLocator | Q | A | ------------- | --- | Branch? | master | Bug fix? | no | New feature? | yes | BC breaks? | no | Deprecations? | yes/no | Tests pass? | yes | Fixed tickets | #27661 | License | MIT | Doc PR | symfony/symfony-docs#9973 As described in #27661 this PR suggests to always load doctrine event listeners lazily from a service locator instead of the full service container. If we agree to move forward I could tackle the remaining todos: - [x] update UPGRADE.md - [x] documentation PR - [x] tested on real app Commits ------- 130ec05 [DoctrineBridge] always load event listeners lazy via ServiceLocator
…Symfony 4.2 change (dmaicher, javiereguiluz) This PR was merged into the master branch. Discussion ---------- [DoctrineBridge] update doctrine event listeners doc for Symfony 4.2 change See symfony/symfony#27675. Doctrine entity listeners are always lazily instantiated as of Symfony 4.2. Commits ------- 4409fd6 Explain that lazy listeners are mandatory, not default b56ef9e Update event_listeners_subscribers.rst d8bb849 Reworded and added the versionadded directive 601450e Update event_listeners_subscribers.rst
As described in #27661 this PR suggests to always load doctrine event listeners lazily from a service locator instead of the full service container.
If we agree to move forward I could tackle the remaining todos: