mirror of
https://github.com/doctrine/orm.git
synced 2026-03-23 22:42:18 +01:00
Drop table migration_versions after doctrine:schema:update --complete #6113
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @4n70w4 on GitHub (Nov 26, 2018).
Originally assigned to: @Ocramius on GitHub.
Bug Report
Summary
Current behavior
How to reproduce
I use doctrine/migrations, doctrine/orm and etc. But command
php bin/console doctrine:schema:update --dump-sql --completegenerate and execute code:
DROP TABLE migration_versions;Expected behavior
I expect that the table migration_versions should not be deleted!
@Tomsgu commented on GitHub (Nov 26, 2018):
And what is the reason for using migrations and schema:update in the same time? If this would magically work (try to think what would need to be done), you would have a broken database version anyway and couldn't use migrations after your schema:update (even if you have
migration_versionstable).@4n70w4 commented on GitHub (Nov 26, 2018):
@Tomsgu this way (combine migration and scheme:update) was suggested by your open-source colleague @Ocramius in a neighboring issue #7485
@Tomsgu commented on GitHub (Nov 26, 2018):
His suggestion was to use only migrations, because schema:update is not that flexible (you can't write additional DB changes by hand) and in advance is not meant for production usage.
@4n70w4 commented on GitHub (Nov 26, 2018):
@Tomsgu in case use only migrations there are also problems with the loss of charset.
https://github.com/doctrine/migrations/issues/766
@Tomsgu commented on GitHub (Nov 27, 2018):
@4n70w4 The advantage of using migrations is that you can modify each migration by hand.
According to "how to change collation and charset faq question" you can't set these values inside the annotations, yml or xml mapping files.
What you can do is to write manual migration that change each table's/database's collation.
@Ocramius commented on GitHub (Nov 27, 2018):
Closing here: the schema tools are not a production DB management system, and ORM doesn't (nor should) know anything about migrations either.
A possible solution is to put the migration tracking table in a different schema, but really, ORM schema tooling is loud and clear enough about not being supposed to be used in production.
@jwage commented on GitHub (Dec 5, 2018):
Maybe try this:
This will cause the Doctrine DBAL to not return
migration_versionswhen listing the available tables to compare to the tables defined by your entities.@darius-v commented on GitHub (Jul 29, 2021):
In symfony 5.3 I had this problem when generating migration - it used to add drop table migration_versisons.
Helped adding
under doctrine_migrations config
Running
php bin/console config:dump-reference doctrine_migrationswas showing null for that table. So it probably needed to know the table name which to skip.
@netandreus commented on GitHub (Apr 25, 2023):
Confirmed at symfony 6.2.9 and:
php composer.phar info | grep doctrine
If we do this:
Then doctrine:schema:update does not working:
@Arkemlar commented on GitHub (Sep 28, 2023):
@netandreus suppose you have a typo and meant "Then doctrine:migrations:migrate does not working:"
@Arkemlar commented on GitHub (Sep 28, 2023):
@Ocramius I not agree with clothing this issue. Its totally true that
schema:updateis not valid thing for production BUT during development it is quite handy and I tend to use it.And now we (developers) are in stupid situation:
schema:updateschema:updatetries to delete migration table locally, that's not goodschema_filterto dbal config (aka$config->setFilterSchemaAssetsExpression()) to exclude doctrine_migration_versions tableschema:updatestops trying to delete migration table BUTmigrations:migratestops working with error:Duplicate table: 7 ERROR: relation "doctrine_migration_versions" already existsThe problem is that we cant use both instruments at same time without pain.
Why doctrine makes discomfort on empty place and make people waste hours to investigate how to overcome this problem?
@Crovitche-1623 commented on GitHub (Oct 6, 2023):
For those who have the same problem (@Arkemlar):
Doctrine seems to create the migration table automatically if it does not exist (if I understand correctly?).
If the table name is changed:
and the following filter (as explained in the Symfony documentation is configured):
The exception
"t___doctrine_migrations_versions" already existsis thrown when the commandsdoctrine:migrations:*are run, I had to use the following filter (inspired by the provided example in this documentation) to exclude my tables beginning witht___:@Arkemlar commented on GitHub (Nov 1, 2023):
@Crovitche-1623 This has no effect for me.
I have following config:
doctrine-schema-updatekeeps willing to deletedoctrine_migration_versionstable.So whatsoever, problem is not fixed 😒
@alexandre-le-borgne commented on GitHub (Apr 30, 2024):
Workaround for Symfony
I'm a bit sad to have had to do this and I blame DoctrineMigrationsBundle
Supports calls of commands inside a command
@xgc1986 commented on GitHub (Jun 2, 2024):
I add my KISS solution, maybe is not the cleanest but I believe is the simplest and easiest workaround. And there is no need to change any config and the only downside is that you have this unnecessary entity with all the other ones
Instead of applying the configurations written above, I integrated the doctrine_migration_version with my entities. With just that my migrations and doctrine works as usual.