-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[DoctrineBridge] Deprecate passing doctrine subscribers to ContainerAwareEventManager #49918
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
[DoctrineBridge] Deprecate passing doctrine subscribers to ContainerAwareEventManager #49918
Conversation
aa48526
to
365b0a5
Compare
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.
Round 1!
1e60b77
to
82db040
Compare
b8d773a
to
0937e41
Compare
...ridge/Doctrine/DependencyInjection/CompilerPass/RegisterEventListenersAndSubscribersPass.php
Outdated
Show resolved
Hide resolved
src/Symfony/Bridge/Doctrine/Tests/ContainerAwareEventManagerTest.php
Outdated
Show resolved
Hide resolved
Given that subscribers are not deprecated in Doctrine, I don't think we should deprecated them either. It would make it a pain to register a subscriber belonging to a third-party package. |
A subscriber can be registered as a listener so it's possible for 3rd parties to adapt and keep supporting a wide range of versions. |
0937e41
to
eee47c7
Compare
But what is the benefit of deprecating passing subscribers here ? It will force bundles registering third-party subscribers to duplicate the subscription mapping, and it will not allow us to simplify the code because we cannot remove support for subscribers in 7.0: they are part of the doctrine/event-manager API. |
We should also update the @stof the benefit is to make it clear that using subscribers as services is wrong. It's wrong because they break important laziness expectations. |
I don't think we should do that, as static analysis tools would then report callers as being broken (while a deprecation should not break things) |
We've always been doing that. SA is not part of our BC promise. |
6a4518f
to
4955431
Compare
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.
(failures unrelated)
4955431
to
1a29f01
Compare
…wareEventManager, use listeners instead
1a29f01
to
c08780e
Compare
Thank you @alli83. |
…ed (alli83) This PR was merged into the 6.3 branch. Discussion ---------- [DoctrineBridge] skip subscriber if listener already defined | Q | A | ------------- | --- | Branch? | 6.3 | Bug fix? | no | New feature? | no | Deprecations? | | Tickets | | License | MIT | Doc PR | Following #49918 and doctrine/DoctrineBundle#1650 skip doctrine event subscriber if a doctrine event listener is already defined for the same definition. Commits ------- 5a867c5 [DoctrineBridge] skip subscriber if listener already defined
…iereguiluz) This PR was squashed before being merged into the 6.3 branch. Discussion ---------- [Doctrine] Deprecate Doctrine lifecycle subscribers Related to symfony/symfony#49918 and doctrine/DoctrineBundle#1664 Commits ------- 77769de [Doctrine] Deprecate Doctrine lifecycle subscribers
Following issue #49586, this PR aims to deprecate passing doctrine subscribers to ContainerAwareEventManager. As mentioned, "[#[AsDoctrineListener]]... is a way better alternative anyway."
Following #49387 (comment), in PR #49610 DoctrineSchemaSubscribers have already been deprecated in favor of listeners.