What is the difference between
symfony doctrine:generate-migrations-db
and
symfony doctrine:generate-migrations-models
I can't notice any difference: I've tried with tables IN DB, NO schema.yml and NO models, both of them have no effect. No migrations generated.
I've tried with tables IN DB, GENERATED schema.yml and NO models, both of them have no effect. No migrations generated.
And lastly I've tried with tables IN DB, GENERATED schema.yml and GENERATED models, now both of them generate the same migrations classes :|.
Can't really understand the difference. Or at least, what is the best way to start using migrations considering all scenarious: having models, but no DB and having DB, but no models.
Thanks.
Given an existing database with 1+ tables, running
./symfony doctrine:generate-migrations-db
will result in migration files being created for each table. Similarly, given a directory like /lib/model/doctrine filled with pre-existing model classes, running
./symfony doctrine:generate-migrations-models
will result in migraiton files being created for each model.
With tables in the database, with or without schema.yml contents, and no models in lib/model/doctrine, you just need to ensure you're database.yml file has credentials to correctly connect to your database.
Once you figure out the problem with your migrations files not generating, what I would do is something like to get started with migrations.
Generate a fresh schema from your existing database with ./symfony doctrine:build-schema
Manually clean up the schema file, and re-establish your relations you're already got existing in your model files (if any).
Reconfigure config/databases.yml to point to a new blank database
Build migrations with ./symfony doctrine:generate-migrations-diff. This will create migrations based on your schema file to bring your (blank) database up to date
Run ./symfony doctrine:migrate and watch for errors. Fix them by fixing your schema file. Delete the migrations created in Step 4. Flush your databse ./symfony doctrine:drop-db && ./symofny doctrine:build-db and go back to Step 4. Continue until you're schema generates a clean set of migrations files that can run without error.
Rebuild your models with ./symfony doctrine:build --model --forms --filters
Now you have a clean schema.yml file, clean migrations that can bring a blank database up to date, and models that directly relate to your schema.yml file and database.
When you want to make a new change to your database, it's now as simple as
Make the desired change in your schema.yml
Run ./symfony doctrine:generate-migrations-diff
Manually review the generated migrations
Run ./symfony doctrine:migrate to make sure the migrations run without error
Rebuild your model, forms, and filters ./symfony doctrine:build --model --forms --filters
Going through this process can be frustrating at times, but it's something you only have to do once to create a really good based to build upon.
Related
I have a .NET Core Project with lots of migrations in it. I also have the database (given to me and not generated with migrations on my pc). now
When I try to add a migration I get an error that there are pending migrations and I first need to update database and I you can guess running update-database command gives me:
object ... already exists error
If I remove database update-database command will generate the whole database however there are lots of data in the database that creating data with migrations would wipe them out.
I thought of generating data script from database, then creating database with migrations and then running the script, but the data script is very large and running the script have lots of other issues.
I just need to remove the old migrations but not unapplying them (as it would also remove my tables from database).
And also note that there are no _MigrationHistory Table in the database
If there is no __MigrationHistory table in the database and you want to omit the migrations, you can also comment the Up and Down fields in the migration files and apply migration. It does not affect your database and only add migration record to __MigrationHistory table.
Note: This problem might occur sometimes and using the approach above most probably fix the problem without affecting data. There are of course some other workarounds that can be applied for such a kind of problem.
I read that __MigrationHistory table is used solely by EF.
I have a team working on the same project and we always have problems with the versioning files EF6 create in the application, and I have to delete them every time I create a migration and someone created another before me (the same happens with the other team members).
Is there a way to restore a previous version of a database schema using the data in __MigrationHistory table alone? Or is it not possible without the versioning files EF6 creates in the application?
The clean way is to define the Down() method in the migration files correctly. Then you can go back to a certain version of the DB with the following command:
Update-Database -TargetMigration <Name of last migration to be applied>
Sometimes, you can also make EF happy by just adding an empty migration after the two migrations to be "merged". This empty migration is just there so EF can update its internal state and write it to _MigrationHistory correctly. This should get rid of the "Unable to update database to match the current model because there are pending changes and automatic migration is disabled." error.
To prevent the problems with migrations being created in parallel you have described, we always use the following process:
Only one team should have changes to the DB model checked out at any time
Before adding a new migration, always get latest version and apply Update-Database
Only now make the changes to the POCOs / ModelBuilder / DbContext
Add your migration with Add-Migration and also define the Down() method
Check in your changes before anyone else is allowed to make changes to the DB model
Track the migrations to be applied in an Excel file (for maintenance / support)
Note that model changes are tracked per DbContext, so maybe it is possible to split the DbContext into one separate context for each team. This would result one set of migrations per DbContext, i.e. team.
I have deleted and modified somes tables in database sqlserver manually, then I have deleted __MigrationHistory table...
Now, when i run "add-migration" command, it regenare commands for recreate entire structure of database, but I want to syncronize the structure from the model to database, without recreates all tables in database...
the comnand "add-migration -ignoreChanges" is not correct, because the
model of website is different from database, because i have manual
modified somes tables.....
is possibles?
thanks
With the command-line option, I tried to do the multiple-schemas thing: have a gold schema with the metadata table, and a series of user sandboxes slaved to it.
flyway -schemas=SCHEMA1,SCHEMA2 clean
This worked OK. All the schemas were wiped.
flyway -schemas=SCHEMA1,SCHEMA2 init
This worked OK, or at least as I expected: only created metadata table in the first schema.
flyway -schemas=SCHEMA1,SCHEMA2 migrate
This did not work - only migrated the first schema, subsequent were ignored.
Is this broken in 2.1.1? This seems like the basic point of having multiple schemas.
I maintain a Django project with a database that has several model constraints that have fallen out of sync with the actual database. So, for example, some model fields have null=False set, but the database permits NULLs for the corresponding database column.
I'm curious if there is a utility, either in Django or a third-party Python script, that will compare the SHOW CREATE TABLE output (in this case, using MySQL syntax) for each table and compare it with the python manage.py sql output, to highlight the discrepancies.
Granted, in an ideal situation, the database wouldn't fall out of sync with the Django model code in the first place, but since that's where I am, I'm curious if there's a solution to this problem before I write one myself or do the comparison manually.
./manage.py inspectdb generates the model file corresponding to the models that exist within the database.
You can diff it with your current model files using a standard unix diff or any other fancy diffing tool to find the difference and plan your migration strategy.
While the former seems simpler and better, you can also see the diff at the sql level. ./manage.py sqlall generates the sql for the current db schema and correspondingly show create table table-name shows the sql for the table creation.
You might want to refer http://code.google.com/p/django-evolution/ which once auto migrated the state of the db to the one in the current models. - Note however, that this project is old and seems abandoned.
I did come up with a quick and dirty means of doing what I described. It's not perfect, but if you run ./manage.py testserver, the test database will be created based on the model code. Then (using MySQL-specific syntax), you can dump the schema for the regular database and the test database to files:
$ mysqldump -uroot -p [database_name] --no-data=true > schema.txt
$ mysqldump -uroot -p [test_database_name] --no-data=true > test_schema.txt
Then you can simply diff schema.txt and test_schema.txt and find the differences.
For PostgreSQL, do a manage.py syncdb on a temporary empty database, then dump production and temporary databases with pg_dump -sOx and compare the resulting files. Among visual diff tools, at least GNOME Meld seems to cope well with PostgreSQL dumps.