There's a lot of articles on this topic and I've spent hours reading them today. It's so confusing - most of the articles seem to try to save existing databases and even migration history.
My databases were created initially by code first migrations. I really don't have any data that's important to keep. So I would like to just delete my databases and the .cs migration history files in /Migrations folder. Then run add migrations and update-database to recreate the databases.
From what I'm reading, this is not the way to do it? My confusion is partially due to the totally different procedures suggested and the extensive coding for many solutions.
Can I delete my databases and /Migrations/*.* (except for Configurations.cs) and essentially reinitialize Migrations?
Btw, I am using VS Web Express 2013, MVC5/C#, SQL Express 2012.
I regularly do this during the development phase of my projects, as long as you are happy to lose your data then it is fine to delete the database, and migration classes, the database will be recreated when you run update-database.
During early development phases, my approach is to utilise automatic migrations and just use update-database which means nothing is created in the migrations folder, so you don't have to manage the extra files.
Obviously this approach isn't good once you start deploying the database for real, where I personally wouldn't use automatic migrations.
To enable automatic migrations, run the Enable-Migrations –EnableAutomaticMigrations command in the Package Manager Console.
More reading:
http://msdn.microsoft.com/en-us/data/dn481501.aspx
http://msdn.microsoft.com/en-gb/data/jj554735.aspx
Related
When I perform flyway clean, it removes everything from my public database including all tables, but also all routines.
The problem is that when I perform my first migration, i'm using Postgres's routine gen_uuid. Consequently, the migration fails and i'm stuck in a loop.
Is that normal ?
I found the answer, turns out there were a strong coupling between migrations written by the previous team on 2 pg extensions, pgcrypto and unaccent that was NOT written as migrations by us but by another container in the stack.
The solution is to let Flyway manage the creation of these extensions.
I currently have an efcore 2.1 project with about 230 entities and about 350 migrations. Every time i add an efcore migration, a designer file is created. This file is approximately 535 kb and growing (150mb total for alle designer files). This makes the IDE slow and unresponsive, refactoring is a no go, it also makes the build process slower. If i delete all designer files, the build goes down from 110 to 20 seconds, and the IDE gets snappy again.
however, once I delete all designer files, i'm not able to work with the "dotnet ef database" command.
I have also previously merged all migrations. this worked, except there were some issues doing this in a team setting (had to run manual commands on each developer machine, no team members could have any unsynced migrations etc) and it is only temporary as the migrations start piling up again after a while.
I am curious if there are other projects with the same problem, and how they work around this?
Now, in the future, it's possible to add an .editorconfig file to the Migrations folder, with the following contents:
# All files
# Sets generated code for all migrations
[*]
generated_code = true
It will disable all analyzers, which makes my IDE much happier with all the migrations.
Note: requires Visual Studio 16.5
You can use another assemblies to manage migrations.
You can try to purge your migration files. I sometimes use it to keep the data module small and compilable. You can find this link useful.
I think your question is a duplicate of Recommended way to clean old Entity Framework Core migrations and Entity Framework Core: Is it safe to delete Migration.Designer.cs if we will never Revert a migration?. The whole topic is discussed in various answers on these threads.
I suggest to consider my answer in order to get your IDE snappy again and to reduce compilation time. And in the long run, it seems good practice to roll-up all migrations into one from time to time. If this is not urgent in your case, you might want to wait for this feature (planned for .NET 6) that allows you to do so in a simpler way.
I am using Entity Framework 6.1.3 Data migrations along with code first.
I am in the process of resetting the migrations. I have deleted the migrations history table and created a new baseline snapshot of the current state of the db. Everything works fine on a new install with the following intializer:
Database.SetInitializer(new MigrateDatabaseToLatestVersion<T>, Migrations.Configuration>(true));
However, how should one deploy this reset to our customers who have an existing database? This fails locally when i have an existing db with the error:
There is already an object named '*****' in the database.
Does anyone have a better approach when needing to reset migrations and synchronizing schemas of existing databases?
I set out thinking I needed to reset my migrations because previous developers on my team were not using the Add-Migrations script correctly. This was causing the following error:
However, I wasn't sure how that would work out for existing customers. I didn't realize that I was able to re-scaffold my migrations. After much SO searching and trial and error, I was able to save my migrations. I first migrated to a migrations that was in a good state.
It was important to use the fully qualified name given. After trial and error I found a stable migration. I verified this by running the following:
It would succeed if EF could fully reconcile. I also had to exclude from VS project, all the migrations following the recently targeted migration. Simple shift select, right click and exclude from project.
Then I added the next migration back to the project after i updated the database. I also used the fluent API to exclude all the model changes following the currently targeted migration.
Then I incrementally re-scaffold all the broken migrations.
Then at the very end I created an idempotent script of my schema up to this point. Using the following:
My migrations are now not complaining about model mismatch and I am happy.
I have set up my mvc project and in my localdb/MSSQLLocaldb there are two databases - the defaultconnection for the identity AspNet tables and the database for my project (the db is called BeforeDb). I have updated some of the tables and run migrations.
But I just watched Scott Allens tutorial https://app.pluralsight.com/player?author=scott-allen&name=aspdotnet-mvc5-fundamentals-m6-ef6&mode=live&clip=3&course=aspdotnet-mvc5-fundamentals
And in that it is a much more elegant solution than mine. So my question is can i delete my db and the migrations folder and the migration history table and implement the way Scott has and build my solution again? One of my questions is whether there is migration info hiding in config files, etc. that i also would need to delete or is all the migration details in the migration history table and folder.
Regards
Before anyone marks this as a duplicate, none of the questions similar to this addressed any of my concerns or answered any of my questions.
I am currently developing all the POCOs and data contexts in a library project, and running migrations from within this project. The database I'm updating is the development database.
What do I do if I want to create the current schema to a fresh, new database? I figure that all I have to do is to change the connection string in web.config and run Update-Database, correct?
While the live/production database is up and running, I want to add new columns and new tables to the schema, and test it out in development. So I switch back the connection string to the development database's connection string, and run Update-Database.
Going back and forth between two databases seems like I'll get conflicts between _MigrationHistory tables and the auto-generated migration scripts.
Is it safe to manually delete the _MigrationHistory tables in both databases, and/or delete the migration files in /Migrations (so I'll run Add-Migration again)? How do we manage this?
What do I do if I want to create the current schema to a fresh, new database?
- Yes, to create fresh database to the current migration level you simply modify the connection string to point to a database that does not yet exist and run update-database. It will run all the migrations in order.
As far as migrating to the Production database, I am running the update-database command with the -script switch to acquire the raw sql and then applying that script to the production database manually. This is helpful if you need to keep a record of sql commands run against the database as well. Additionally, you can generate the script explicitly from a specific migration to another specific migration via some of the other update-database switches.
Alternatively, you can create an Idempotent script that works from any migration by using the–SourceMigration $InitialDatabase switch and optionally specify an end migration with –TargetMigration
If you delete the _MigrationHistory tables you will have issues where the generated script will be trying to add columns that already exist and such.
You may find the following link helpful:
Microsoft Entity Framework Migrations
I would suggest having a separate trunk in your source code repository - one pointing to production and one to development to avoid risks of switching between the two in visual studio.
Me also had the same problem, even when using one and the same database - due to some merges in the repository, and the mix of automatic/manual migrations. For some reason the EF was not taking into account the target database, and calculating what scripts need to me executed, based on what is already in the database.
To fix this, I go to the [__MigrationHistory] table on the target database and get the latest migration name. This will help EF to determinate the state of the DB, and will execute just the scripts needed.
then the following script is run:
update-database -script -sourcemigration {latest migration name}
This creates update script that is specific to the target database (the connection string should be correct, as discussed in the other comments)
you can also use -force parameter if needed
this way you can update any database to latest version, no mater in what version you found it, if it has MigrationHistory table.
Hope this helps
My production and my developmental database went out of synch and it gave me endless problems. I solved it using a tool from Red-Gate to match up the databases. After using the tool, the databases were exactly the same but my migration was not working and I started to get odd errors i.e. trying to add tables/ columns that already existed etc. I solved that. I just deleted the migration folder on the local, recreated it, added the initial migration, updated the database and then matched the data of this migration file (local) to the one on the host (delete all the data in the migration file on the host, and add the same data that is on the local into the host). A more detailed explanation is at:
migration synch developmental and production databases