Skip to content
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

Add ContainerEntityListenerResolver + load listeners lazy by default #951

Merged
merged 8 commits into from Apr 11, 2019

Conversation

dmaicher
Copy link
Contributor

@dmaicher dmaicher commented Apr 7, 2019

EUFOSSA

This implements #899

  • rename ContainerAwareEntityListenerResolver into ContainerEntityListenerResolver + deprecate old class
  • make entity listener services lazy by default (if no lazy tag attribute specified)
  • use service locator as a smaller container for resolving services

I tested this on my huge work project which uses Symfony 3.4 and we have 3 entity listeners:

Information for Service "doctrine.orm.default_entity_listener_resolver"
=======================================================================

 ---------------- ------------------------------------------------------------------------ 
  Option           Value                                                                   
 ---------------- ------------------------------------------------------------------------ 
  Service ID       doctrine.orm.default_entity_listener_resolver                           
  Class            Doctrine\Bundle\DoctrineBundle\Mapping\ContainerEntityListenerResolver  
  Tags             -                                                                       
  Calls            registerService, registerService, registerService                       
  Public           yes                                                                     
  Synthetic        no                                                                      
  Lazy             no                                                                      
  Shared           yes                                                                     
  Abstract         no                                                                      
  Autowired        no                                                                      
  Autoconfigured   no                                                                      
  Arguments        Service(service_locator.hpxy8ox)                                        
 ---------------- ------------------------------------------------------------------------ 

@OskarStark
Copy link
Contributor

Maybe add a test that the deprecation is raised?

@dmaicher
Copy link
Contributor Author

dmaicher commented Apr 7, 2019

Maybe add a test that the deprecation is raised?

@alcaeus should we test this? I think you said its not needed?

@alcaeus alcaeus added Feature ⭐️ EUFOSSA Hackathon https://symfony.com/blog/the-symfony-and-api-platform-hackathon-is-coming labels Apr 7, 2019
@alcaeus alcaeus added this to 1.11 in Roadmap Apr 7, 2019
@alcaeus
Copy link
Member

alcaeus commented Apr 8, 2019

Maybe add a test that the deprecation is raised?

@alcaeus should we test this? I think you said its not needed?

I don't think it's necessary: the deprecation is dropped anyways and left for the DebugClassLoader to take care of, so I'd argue we don't need to test anything here.

@dmaicher
Copy link
Contributor Author

dmaicher commented Apr 9, 2019

Ready for another round of reviews. Also tested it again with my large work project and it works fine 😊

@alcaeus alcaeus self-requested a review April 9, 2019 16:06
@ostrolucky
Copy link
Member

I guess you guys talked about that, but can you involve others in your decision to deprecate whole class, instead of relaxing __construct typehint in existing class?

@alcaeus
Copy link
Member

alcaeus commented Apr 10, 2019

I guess you guys talked about that, but can you involve others in your decision to deprecate whole class, instead of relaxing __construct typehint in existing class?

Relaxing the type hint from the Symfony ContainerInterface to the PSR ContainerInterface would have worked without other changes as the original type implements the new type and constructor signature changes don't generate method mismatches in extending classes. However, we decided to deprecate the class to get rid of the ContainerAware naming and for consistency with other classes like ContainerRepositoryFactory. At the time, I wouldn't have known who else to include in the discussion.

Copy link
Member

@alcaeus alcaeus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good, great work @dmaicher!

sprintf('Lazy-loaded entity listeners can only be resolved by a resolver implementing %s.', $interface)
);
// if the resolver uses the default class we will use a service locator for all listeners
if ($resolverClass === ContainerEntityListenerResolver::class) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd like to get rid of this logic for 2.0, but for now this is perfectly fine 👍

@alcaeus alcaeus requested a review from a team April 10, 2019 05:25
@ostrolucky
Copy link
Member

I would say old name would fit this change too, since it's still aware of container, just not the main one. But yeah I don't mind

@alcaeus alcaeus merged commit f5c10ec into doctrine:master Apr 11, 2019
@alcaeus
Copy link
Member

alcaeus commented Apr 11, 2019

Thanks @dmaicher! 🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
⭐️ EUFOSSA Hackathon https://symfony.com/blog/the-symfony-and-api-platform-hackathon-is-coming Feature
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants