You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a SF 4.4 app, originally created using the 'website-skeleton' composer package. As such, it does pull in orm-pack, which includes both doctrine and doctrine migrations.
The app's goal is to manage multiple databases, and as such it does not have a doctrine default connection set up.
In fact, it has no doctrine dbal connections defined at all (it sets up db connections on the fly when needed).
It also does not use doctrine migrations - even though it might in the future if the need arises...
Previous behaviour
The app worked fine.
Current behaviour
When running composer upgrade, doctrine migrations got bumped to 3.0.1. In the process, the Sf console command broke.
To fix that, I had to manually set the migrations_paths config in doctrine_migrations.yml.
However, as soon as I ran bin/console, I got an error:
The service "doctrine.migrations.dependency_factory" has a dependency on a non-existent service "doctrine.dbal.default_connection".
Questions
Is it still possible to have Migrations installed without defining a db connection? If so, how can it be achieved? Reading around other bug reports, it seems that defining a custom default entity manager might do the trick, but it does not seem trivial for this scenario...
Given all the 'magic' happening with Symfony Packs, Flex and whatnot, I was slightly surprised to see a simple composer update break the app. Did I miss running any command that would have updated the config files automatically for me? If not, how comes that the standard set of dependencies for SF 4.4 apps does allow the bc-break-inducing Migrations 3.0 package to creep in?
The text was updated successfully, but these errors were encountered:
I had a similar problem with SF5.2 and I have made a small fix for this issue. Setting the connection configuration would do nothing when you are using the "default" entity manager.
BC Break Report
Summary
I have a SF 4.4 app, originally created using the 'website-skeleton' composer package. As such, it does pull in orm-pack, which includes both doctrine and doctrine migrations.
The app's goal is to manage multiple databases, and as such it does not have a doctrine default connection set up.
In fact, it has no doctrine dbal connections defined at all (it sets up db connections on the fly when needed).
It also does not use doctrine migrations - even though it might in the future if the need arises...
Previous behaviour
The app worked fine.
Current behaviour
When running composer upgrade, doctrine migrations got bumped to 3.0.1. In the process, the Sf console command broke.
To fix that, I had to manually set the
migrations_paths
config in doctrine_migrations.yml.However, as soon as I ran
bin/console
, I got an error:The service "doctrine.migrations.dependency_factory" has a dependency on a non-existent service "doctrine.dbal.default_connection".
Questions
Is it still possible to have Migrations installed without defining a db connection? If so, how can it be achieved? Reading around other bug reports, it seems that defining a custom default entity manager might do the trick, but it does not seem trivial for this scenario...
Given all the 'magic' happening with Symfony Packs, Flex and whatnot, I was slightly surprised to see a simple composer update break the app. Did I miss running any command that would have updated the config files automatically for me? If not, how comes that the standard set of dependencies for SF 4.4 apps does allow the bc-break-inducing Migrations 3.0 package to creep in?
The text was updated successfully, but these errors were encountered: