Support query inference with multiple entity managers

[LubuSeb]

Summary

Fixes return type inference for projects that use multiple Doctrine entity managers by allowing objectManagerLoader to return a Doctrine ManagerRegistry.

When the loader returns a registry, PHPStan Doctrine now resolves the object manager from the entity class found in the DQL before validating or inferring query result types. This keeps the existing single-manager loader behavior intact while supporting Symfony applications where each entity namespace is owned by a different manager.

Details

• Add ManagerRegistry support to ObjectMetadataResolver.
• Resolve entity metadata and DQL/query-builder analysis through getManagerForClass() when possible.
• Add a regression fixture with two in-memory entity managers mapped to disjoint namespaces.
• Document returning the Doctrine registry from Symfony objectManagerLoader setups.

Verification

• vendor/bin/phpunit
• Verified the repro from Repository return type errors when using multiple entity managers #655 by returning the Symfony Doctrine registry from objectManagerLoader and running PHPStan against tedyno/phpstan-multiple-em-issue; it reports no errors with this branch.

Fixes #655

[VincentLanglet]

Looking at https://github.com/phpstan/phpstan-doctrine/pull/757/changes#diff-e1bfea71addecdb2a3f73f91d95ed61b789458e5107d9efbbc39937d35b880fd some updates are also needed in GetRepositoryDynamicReturnTypeExtension no ?

[LubuSeb]

Addressed the repository return-type path as well: the extension now reads the optional manager name argument and resolves the repository class through the matching object manager. I also fixed the lowest-dependency ObjectManager fixture compatibility issue and the coding-standard findings from the last run. CI is green on the latest head.

[LubuSeb]

Addressed the latest resolver simplification feedback in 3568a87.

Changes made:

• getObjectManagerLoaderResult() now normalizes a ManagerRegistry with exactly one manager into that single ObjectManager when caching the loader result.
• getObjectManager() and getObjectManagerForClass() now return early when the cached loader result is not a registry.
• getObjectManagerForDql() now avoids the DQL class parsing path entirely for non-registry loader results.
• Removed the separate single-manager helper.

Validation:

• parallel-lint on ObjectMetadataResolver.php passed.
• Targeted PHPUnit for multiple-EM, named-manager repository, and ManagerRegistry inference passed: 8 tests / 8 assertions.
• Broader tests/Type/Doctrine passed: 279 tests / 8072 assertions.
• PHPStan analysis of ObjectMetadataResolver.php and GetRepositoryDynamicReturnTypeExtension.php passed.
• phpcs on ObjectMetadataResolver.php passed.
• GitHub CI is green on head 3568a87.

[VincentLanglet]

Even if you don't use doctrine ; I saw you worked a lot with regex, so I'd like your opinion on this strategy @staabm

[staabm]

do I see this correctly, that we need this regex-magic, because we cannot get a AST for the DQL since we are in the process of creating a entity manager?

[staabm]

will the DQL always contain a full-qualified class-name in the query?

[staabm]

I don't see a test which contains a DELETE statement.. is this line tested?

[LubuSeb]

Yes, that's the reason for the pre-parse step. At this point we need a candidate entity class before handing the DQL to Doctrine's EM-bound parser/metadata validation; otherwise the default manager can reject a tenant entity before we know which manager should parse it. The regex is intentionally a narrow heuristic to find an autoloadable root entity class, then the actual manager choice is delegated to ManagerRegistry::getManagerForClass().

[LubuSeb]

No, not universally. This only supports the autoloadable class-string path. QueryBuilder/repository-generated DQL uses class metadata names, and direct createQuery() inference can resolve those FQCN-style class strings. If the DQL uses a short alias or anything not autoloadable, this falls back to the default configured manager rather than guessing.

[LubuSeb]

Good catch. I added focused coverage in badaaae using Doctrine's no-FROM form, DELETE QueryResult\MultipleEntityManagers\Tenant\App a, so it exercises the DELETE-specific extraction branch rather than the generic FROM branch.

Verification run in Docker with PHP 8.4:

• vendor/bin/phpunit tests/Type/Doctrine/MultipleEntityManagersQueryTypeInferenceTest.php -> 9 tests / 9 assertions
• vendor/bin/phpunit tests/Type/Doctrine -> 280 tests / 8073 assertions
• git diff --check -> clean

[staabm]

@stof do you forsee whether this regex-matching is "good enough" for most DQL to identify the used entity-class?
(I am no DQL expert and don't know which syntax people use/is supported)

in case we can think about more DQL syntax edge cases, this might help to add more tests and harden the regex pattern