7

The project I am working on is using Entity Framework 4.3 and data migrations to keep the schema up to date. Over the course of the project the migrations folder has grown and now has over 600 files. This is huge. We now have a binary which is over 12MB due to all the migration meta data.

I would like to collapse all these in to one migration and start again. My concerns are:

  1. Is this possible or will it cause problems with the migration history if I remove migrations?
  2. Are there any guides around describing how to do this?
Gates VP
  • 44,957
  • 11
  • 105
  • 108
Keith Bloom
  • 2,391
  • 3
  • 18
  • 30

2 Answers2

7

First: I recommend that you keep your migrations in a separate assembly so they don't have to be published with the application. It could be a simple console app that applies the migrations or a winforms GUI that generates scripts. But there's no reason for it to be deployed with the app imo.

Second: Understanding that you'd be giving up the ability to roll back to previous versions, you could just exclude-from-project all of your prior migrations then generate a new one which should then be able to create a database reflecting your current model. That would serve as your new starting point. Remember that EF doesn't always generate code to do everything you want in a migration, so you might have some hand-written migration code in other migrations you'd need to pull in.

JC Ford
  • 6,946
  • 3
  • 25
  • 34
  • Fantastic idea to move the migrations to a different assembly. Do you know if this s this possible with EF 4? I thought the migrations have to live in the same project as the DataContext. – Keith Bloom Apr 02 '14 at 08:30
  • 1
    The DbMigrationsConfiguration derived class just needs to be able to see your DbContext. Two ways to go about it. You could have a separate context in the Migrations project or you could add a reference to your data layer in your Migrations project so it can see the context(s) there. The approach I take is to keep my entities and entity mapping classes in their own separate projects. In my Migrations project I have a special context that doesn't define any DbSets, it just dynamically loads all my entity mapping classes using `modelBuilder.Configuration.AddFromAssembly()` – JC Ford Apr 02 '14 at 12:44
  • I like the separation you've come up with. Does this still allow developers to use Add-Migration and Enable-Migration from the console? – Keith Bloom Apr 02 '14 at 14:32
  • It does. And they can still run update-database from the console too, but it makes me feel better to compile, publish to staging and use the migrations app to generate the scripts. – JC Ford Apr 02 '14 at 17:57
  • Yes, good point about running the process. Thanks for your advice it's very helpful. – Keith Bloom Apr 03 '14 at 10:13
  • 1
    Very good answer. But what if I wanted to do this in production? What if we have 100 migrations that we know we will never want to go back to, and wanted to collapse all of them, but still be able to keep updating our production database with new migrations? Would I need to manually delete or change the MigrationHistory table in that case? I could probably collapse all my migrations in a new "Initial" migration without anything new, and manually clear the MigrationHistory table and insert a single entry to this new initial migration. But is there a more elegant way to do that? – julealgon Oct 08 '14 at 19:18
  • If you were doing away with old migration code, I think you'd want the migration table to match the migrations in your project. Simply clearing that table is what I'd try first. – JC Ford Oct 09 '14 at 13:07
0

Not sure past versions, but if you are here looking for the same solution for EF Core. You should be able to just delete the ModelSnapshot and re-run your migration to create a clean sheet.

markokstate
  • 923
  • 2
  • 14
  • 28
  • As @JC-Ford mentions in his response, there are other artifacts that may be inside each migration, so you should review any of these custom code elements to ensure that they are captured in your new model. We do this as the first minor release after each major release of our applications. – Chris Schaller Apr 16 '19 at 00:12