Allow multiple doctrine ORM instance

[jdeniau]

Fixes #90

[jdeniau]

I don't really know why the tests fails. It does not seems related to this PR

[theofidry]

Thanks for the PR!

The tests seem to fail due to a new release of the Doctrine packages which introduces more deprecation notices. No biggie, but that would need to be fixed in a separate PR.

Regarding the PR itself, I'm having a bit of trouble to understand: so the strategy is to "duplicate" the current services per entity manager and then you leave the responsibility to the user to pick the right one?

[jdeniau]

@theofidry Yes, I used the same strategy that doctrine uses.

Imagine you have the following doctrine configuration:

doctrine:
  orm:
    default_entity_manager: foo
    entity_managers:
      foo: 
        connection: xxx
        # etc.
      bar: 
        connection: xxx
        # etc.

Then doctrine bundle will generate:

• two services named:
  • doctrine.orm.foo_entity_manager
  • doctrine.orm.bar_entity_manager
• an alias named doctrine.orm.entity_manager for the service doctrine.orm.foo_entity_manager.

(and it will also generate 2 services for each cache, entity_listener, etc.).

I applied the same strategy here:

• two services named:
  • fidry_alice_data_fixtures.doctrine.foo_purger_loader
  • fidry_alice_data_fixtures.doctrine.bar_purger_loader
• the old service fidry_alice_data_fixtures.doctrine.purger_loader is now an alias on fidry_alice_data_fixtures.doctrine.foo_purger_loader

[theofidry]

The difference is that when you persist an object with Doctrine, provided you have multiple connections/managers, you want to specify which one as wanting to persist it for all of them is much less likely. In alice however, I think it would be more common the other way around: if you have an entity managed by a manager and another entity manager by another, I think most people would like Alice to figure out which manager should be used for which entity.

So I think a different approach that would work better for most cases would be as @dkarlovi mentioned on Slack:

• fetching all managers
• asking if they are managing the class in question
• if so, call persist() and mark them dirty
• repeat for each fixture loaded
• flush all dirty managers (edited)

Maybe @dkarlovi can also help you out with the implementation

[Zayon]

Any updates on this ? This fix would be appreciated 😄

edit : I did some work (still WIP, need to test) here : #99

[jdeniau]

@Zayon I worked on this here too, but I did not have time to finish this.

Feel free to compare

[theofidry]

Closing as I think @Zayon follow up (#99) is a good take on this. Hope this one gets in :)

[dkarlovi]

Sorry all, I should really queue these tasks better, I should have done a follow-up here, my bad.