Closed lloonnyyaa closed 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
Thanks, sorry, I missed the release documentation
For the sake of BC, this should have been 2.0.0 according to Semver, it now broke my build + update.
This likely needs a revert and to be pushed to the next major
Can the alias remain though?
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.
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?
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.
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?
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?
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 :).
I just tagged 1.9.1 with the revert :)
Thanks Ryan!
fixed in #805 and pushed in 1.9.1
This appears to still be an issue while upgrading to Symfony 4.4. Was the fix for this reverted in a later version?
@natewiebe13 what version of the doctrine bundle are you using?
@greg0ire 2.0.0
@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.
@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
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:
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?