Skip to content

Entity metadata cannot be loaded with multiple entity managers #413

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

Open
Lehren opened this issue May 21, 2024 · 1 comment
Open

Entity metadata cannot be loaded with multiple entity managers #413

Lehren opened this issue May 21, 2024 · 1 comment
Labels
bug Something isn't working

Comments

@Lehren
Copy link

Lehren commented May 21, 2024

Q A
auditor-bundle version 5.2.3
PHP version 8.0.30
Database MySQL

Summary

After updating, I get an error saying that an entity was not found in the chain configured namespaces. This seems to be because I have two entity managers in doctrine.yml that each have separate mappings. These entity managers are also registered as auditing providers. Yet in the code in Provider/Doctrine/Configuration.php all entities are processed for each auditing service, which cannot possibly work.

Doctrine.yml:

doctrine:
  orm:
    default_entity_manager: default
    entity_managers:
      default:
        connection: default
        mappings:
          FirstBundle: ~
      special:
        connection: special
        mappings:
          SecondBundle: ~
            foreach ($auditingServices as $auditingService) {
                $entityManager = $auditingService->getEntityManager();
                $platform = $entityManager->getConnection()->getDatabasePlatform();

                ...

                \assert(null !== $this->entities);
                foreach ($this->entities as $entity => $config) {

                    //Below line fails because an entity is not mapped for the current auditingService/entityManager
                    $meta = $entityManager->getClassMetadata(DoctrineHelper::getRealClassName($entity));

Current behavior

Loading entities crashes and auditing changes therefore does not work

How to reproduce

Have two entity managers setup in doctrine.yml. Each having different entity mappings. Register the entity managers are auditingProviders and try to edit some entities. It will crash on flush because it is trying to load an entity metadata with an entityManager it is not mapped for.

Expected behavior

It should load entities that are mapped to the relevant entityManager, and skip an entityManager if it does not have the correct mapping.

As a workaround I can register every entity to every entityManager, but that is sloppy and bloats the code

@Lehren Lehren added the bug Something isn't working label May 21, 2024
@themasch
Copy link

Same issue here with auditor-bundle 6.2, php 8.2, on mysql.
For whacky reasons we have two entity mangers, where the second one only maps a subset of the entities of the first one.
So, as an example, default_entity_manager has everything unter App\Entity, while foo_entity_manager only maps App\Entity\Foo.

This worked with auditor-bundle 5.2 which seems to only care about the default, but for some reason also gets events (and therefor write audits) for flushes on the foo manager.

With 6.2 I needed to add foo_entity_manager to the auditing_services config, and started to get a crash at the same line as mentioned above. Same problem: it tries to map all entities via ll entity managers, which, afaict, cannot work.

One hacky fix could be to add a try { ... } catch (MappingException) { continue; } around that line, to skip handling an entity if its not mapped in that EM, but implementing it that naive will swallow real errors and the performance is certainly terrible, because unmapped entities will never hit the cache afaik.

I currently do not have a good solution. As far as I can tell there is not way to ask the doctrine configuration if a given entity class is mapped for an entity manager.

One posible way to to "properly" handle this, could be to keep the split between the auditing services consistend over the whole metadata/configuration system, so the entity managers are always separate and a single transaction event is only looking at its own entity manager (which is part of doctrines event object). But I have not looked at enough of the code to be able to say if thats feasible, its certainly looks like it would be a larger refactoring.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants