Support multiple object managers?

[dmaicher]

In my project I have multiple objectmanagers.

This currently leads to errors like:

Internal error: The class 'X' was not found in the chain configured namespaces ...

because its using the wrong objectManager (the one returned in object-manager.php) for some entities.

[dmaicher]

Probably internally we should just return the whole doctrine registry from the php file and use

https://github.com/doctrine/persistence/blob/master/lib/Doctrine/Persistence/ManagerRegistry.php#L87

?

[ondrejmirtes]

Hi,
those two object managers have different entity metadata loaded? Why? How do you keep track of which one should be used where in your application?

I see two possible options:

1. Run PHPStan twice with different configurations on different folders. This assumes that there's a clear cut in these two areas in your application - they are in different folders.
2. Create a third object manager that has all the metadata and pass it to PHPStan. This however can lead to problems since it does not reflect the real state of your application. For example if you mention two different entities in a single DQL that are from different object managers, PHPStan would not find this error.

[dmaicher]

those two object managers have different entity metadata loaded? Why?

different databases 😉

How do you keep track of which one should be used where in your application?

doctrine bundle can handle multiple managers and we can differentiate it based on the context in our app

What do you think about my comment to use the doctrine registry for this in phpstan? is there any drawback? Thats the source of truth that knows which entity is managed by which object manager 😊

[ondrejmirtes]

doctrine bundle can handle multiple managers and we can differentiate it based on the context in our app

What's the "context"?

I really don't know how the ManagerRegistry works - and I don't think that all applications using Doctrine use it. It seems too Symfony-specific.

[ondrejmirtes]

Also, when analysing DQL, it really doesn't go through ClassMetadata, I already need to have an ObjectManager (EntityManager) to run the query on.

[dmaicher]

What's the "context"?

I meant based on bundles/namespaces in our app.

Also, when analysing DQL, it really doesn't go through ClassMetadata, I already need to have an ObjectManager (EntityManager) to run the query on.

Yeah I guess choosing the "correct" ObjectManager for analyzing DQL could be tricky indeed 😕

Maybe running different phpstan configurations on different namespaces/folders is an option. Will have a look.

[ondrejmirtes]

Maybe running different phpstan configurations on different namespaces/folders is an option. Will have a look.

If you differentiate based on that, it sounds usable :)

I'm gonna keep this open since more people might have this problem, so it should be somehow supported.

[alcaeus]

It seems too Symfony-specific.

Not at all: https://github.com/doctrine/persistence/blob/790cc20de53d0e4c943b36c8513401bfb5f34cf1/lib/Doctrine/Persistence/ManagerRegistry.php#L8.

The concept of having multiple entity managers is not limited to Symfony, nor is it an anti-pattern. People who use multiple object managers can use a registry to fetch a manager by name or to fetch the manager responsible for a given entity/class. In fact, this bundle even supports returning the correct repository type for a given object: #46.

The option of having multiple configurations is a workaround, not a solution. For example, in one of our applications we use both MongoDB ODM and ORM. This also means that classes might very well use an EntityManager and a DocumentManager. The extension should support multiple object managers. As is, the feature is incomplete.

[ondrejmirtes]

My point is that in Doctrine itself, there's only the interface and an abstract class. Not all projects use the ManagerRegistry. BTW: It looks just like a service locator pattern under a different name to me ;)

There's some problems around this if I wanted to add support - I have no way of testing it. And I don't know what are the common patterns:

Is that you inject ManagerRegistry into your class-that-uses-EM (just call it service from now on) like this?

/** @var ManagerRegistry */
private $managerRegistry;

public function __construct(ManagerRegistry $managerRegistry)
{
    $this->managerRegistry = $managerRegistry;
}

And use it later like this:

$this->managerRegistry->getManager('a')->getRepository(FooEntity::class)->...

Or is it rather like this?

/** @var EntityManager */
private $entityManager;

public function __construct(ManagerRegistry $managerRegistry)
{
    $this->entityManager = $managerRegistry->getManager('a');
}

Which makes it really difficult when the EM is used later in the class - PHPStan has no idea which one is used because it just sees the property phpDoc. It would have to be annotated like EntityManager<a> which is really ugly.

I can imagine some other combinations too. My point is that it's really difficult to support all of them generally so I must hard-code every pattern like this...

[dmaicher]

In our app we

• get the manager by name from the registry
• or directly inject one of the managers by DI configuration into some classes

So without checking the DI config there is no way to always know which manager is used inside some class for phpstan I'm afraid 😢

[luxemate]

We, for example, have separate symfony bundle, which uses different database and has it's own doctrine config. In services.yml we have:

services:
    _defaults:
        ...
        autowire: true
        bind:
            $em: '@doctrine.orm.exchange_entity_manager'

So everywhere in this bundle where we have function(EntityManagerInterface $em) we get the correct EntityManger injected.

Also ran into that issue today while updating phpstan-doctrine to get rid of these :)

parameters:
    ignoreErrors:
        - '#Call to an undefined method Doctrine\\ORM\\EntityRepository<[a-zA-Z0-9\\_:]+>::[a-zA-Z0-9_]+\(\)#'
        - '#Method .+? should return [a-zA-Z0-9\\]+ but returns Doctrine\\ORM\\EntityRepository<[a-zA-Z0-9\\_:]+>#'
        - '#Method .+? should return [a-zA-Z0-9\\]+ but returns Doctrine\\Common\\Persistence\\ObjectRepository#'
        - '#Method .+? should return [a-zA-Z0-9\\]+ but returns Doctrine\\Common\\Persistence\\ObjectRepository#'
        - '#Property [a-zA-Z0-9\\]+::\$[a-zA-Z]+Repository \([a-zA-Z0-9\\]+\) does not accept Doctrine\\ORM\\EntityRepository<[a-zA-Z0-9\\]+>#'

[luxemate]

Just an idea: accept an array of entity managers and retry with each of them if MappingException: The class 'X' was not found in the chain configured namespaces ... is caught.

[luxemate]

@ondrejmirtes of course catching exceptions is a hacky workaround. This should be better:

$entityManager->getConfiguration()->getMetadataDriverImpl()->getAllClassNames();

Which returns an array of FQCN's of entites managed by that particular entity manager. Not sure about the ODM, but there must be something similar. So we'll end up with returning one entity manager, or an array of managers in object-manager.php. It's especially easy in Symfony via ManagerRegistry::getManagers().

What do you think?

[alcaeus]

Not sure about the ODM, but there must be something similar.

The Symfony Bundle for the MongoDB ODM contains the same manager registry logic as the ORM bundle. They're separate registries but the functionality is exactly the same.

[mcfedr]

I personally always inject ManagerRegistry, the entity managers can be replaced, e.g. if you have an SQL error and reconnect. It probably makes sense to change the file we use for phpstan to return the manager registry which can then give us the correct entity manager pet entity. I guess for generic dql you can use the default manager and most of the time this will be correct