I was running Symfony 4.4.8, and I wanted to update my project. So I ran:
It did automatically update the DoctrineMigrationsBundle (https://packagist.org/packages/doctrine/doctrine-migrations-bundle) from 2.1.2 to 3.0.1.
Composer failed at first because doctrine_migrations.yaml was not compatible with the DoctrineMigrationsBundle 3.0.1, so I ran:
composer recipes:install --force -v composer install
But: it appears that the DoctrineMigrationsBundle v 3 has a totally different configuration and does not use the "migrations_versions" SQL table anymore, but a new "doctrine_migrations_versions"-table and a new migrations directory (‘%kernel.project_dir%/migrations’ instead of ‘%kernel.project_dir%/src/Migrations’).
This means that every time you do:
php bin/console doctrine:migrations:diff
You will get in the migration:
$this->addSql('DROP TABLE migration_versions');
I read at https://symfony.com/doc/master/bundles/DoctrineMigrationsBundle/index.html that you can set the table name in doctrine_migrations.yaml manually like this:
doctrine_migrations: storage: table_storage: 'table_name': 'doctrine_migrations'
But that is of no use, because the v 3 table has an extra column "execution_time" and in the "version" column a namespace is prepended (e.g. "DoctrineMigrationsVersion20200702112735.php"). So both tables are incompatible.
I can’t find any information anywhere on properly upgrading DoctrineMigrationsBundle from v2 to v3.
I must say I am surprised by this, I thought that "composer update" was to be safe. Appearently, one of the symfony bundles didn’t add a version limit automatically where it should if an upgrade is not possible.
So what should I do? Should I just let composer downgrade the DoctrineMigrationsBundle again? Or is there some way to get an upgrade of DoctrineMigrationsBundle from v2 to v3 to work after all?
Source: Symfony Questions
Was this helpful?
0 / 0