doctrine / DoctrineBundle

Symfony Bundle for Doctrine ORM and DBAL
https://www.doctrine-project.org/projects/doctrine-bundle.html
MIT License
4.72k stars 454 forks source link

[Question] Where is ManagerRegistry in 1.9.0 version? #803

Closed lloonnyyaa closed 6 years ago

lloonnyyaa commented 6 years ago

In my project, I use a service (https://github.com/lloonnyyaa/reviews/blob/master/src/Form/Type/EntityHiddenType.php) that depends on ManagerRegistry (Doctrine\Common\Persistence\ManagerRegistry)

After the upgrade doctrine/doctrine-bundle to version 1.9.0 there was an errors: screen shot 2018-04-19 at 12 02 51 pm screen shot 2018-04-19 at 12 03 10 pm

In the config doctrine/doctrine-bundle/Resources/config/dbal.xml I saw that this service is not declared, whereas in version 1.8.1 it was declared: <service id="Doctrine\Common\Persistence\ManagerRegistry" alias="doctrine" public="false" />

Tell me please, will this interface no longer be used?

jvasseur commented 6 years ago

https://github.com/doctrine/DoctrineBundle/releases/tag/1.9.0

Removal of ManagerRegistry and ObjectManager as autowirable aliases. Use RegistryInterface or EntityManagerInterface instead

lloonnyyaa commented 6 years ago

Thanks, sorry, I missed the release documentation

linaori commented 6 years ago

For the sake of BC, this should have been 2.0.0 according to Semver, it now broke my build + update.

Ocramius commented 6 years ago

This likely needs a revert and to be pushed to the next major

linaori commented 6 years ago

Can the alias remain though?

alcaeus commented 6 years ago

I've explained the reason for the change in the original pull request: #740. Long story short, #640 (which became part of 1.6.8 and should've been 1.7.0) introduced some aliases that are incorrectly taken by this bundle: we have multiple implementations for the interfaces defined in Doctrine\Common, and none of the Doctrine integrations should assume ownership of those interfaces, as there will inevitably be conflicts when multiple implementations of those interfaces exist (as happens when people combine ORM and MongoDB ODM for example). Thus, the decision was made to remove those interfaces, as they were added in error.

People should not typehint stuff from Doctrine\Common when they expect ORM implementations. If they want to do so, they should create the necessary aliases themselves to avoid the conflict mentioned above. As bad as the BC break may sound, the original change should never have been introduced.

weaverryan commented 6 years ago

Yea, for sure, these aliases shouldn't have been added.

But, this was a BC break, though, a BC break that (at least) hits you at container "compile time", so it's unavoidable and obvious.

However, I would be fine with a revert and a push to the next major. Unfortunately, it's not possible yet to deprecate aliases, but hopefully we will have that in Symfony 4.2 (and then would could add deprecations to this bundle if the user has this version).

So, revert or leave?

alcaeus commented 6 years ago

IMO it would be ok to revert it, but how do we prepare people for the break? We can't mark aliases as deprecated, so people will still hit the error when upgrading to the next major. One further question is the release date of the new major version - there's no point doing this if we're not releasing a new major in the near future IMO.

kimhemsoe commented 6 years ago

When we revert i will push for a 2.0 very fast with this change and removal of ".class" parameters. Anything else people want removed?

alcaeus commented 6 years ago

We've had the PHP version requirement discussion - maybe a new major version release would be a good opportunity to drop old versions, maybe with a longer support window for 1.9?

weaverryan commented 6 years ago

See #805 for the revert.

@kimhemsoe removing the class params for 2.0 is a good idea. We may be able to find a few other things, and hopefully deprecate them when possible :).

weaverryan commented 6 years ago

I just tagged 1.9.1 with the revert :)

alcaeus commented 6 years ago

Thanks Ryan!

mikeSimonson commented 6 years ago

fixed in #805 and pushed in 1.9.1

natewiebe13 commented 4 years ago

This appears to still be an issue while upgrading to Symfony 4.4. Was the fix for this reverted in a later version?

greg0ire commented 4 years ago

@natewiebe13 what version of the doctrine bundle are you using?

natewiebe13 commented 4 years ago

@greg0ire 2.0.0

natewiebe13 commented 4 years ago

@greg0ire Looking with fresh eyes, my issue wasn't with using Doctrine\Common\Persistence\ObjectManager in the load() function, since that's what's specified in the interface, but with autowiring the ObjectManager in the constructor of the fixture class. This can be ignored.

maxhelias commented 4 years ago

@natewiebe13, The ObjectManager is no longer autowiring to doctrine.orm.entity_manager service since 2.0. Please read the upgrade 2.0 and adjust your code