1

Say I have three migration histories (call it init, m1 and m2). I use package manager to generate all the migration cs files and when I run my website on a live environment, it will update the database to the latest version m2.

Say unfortunately we found a major problem with migration m2 on live and whats to roll back, then what is the right way to do it?

I know that I call run this on my local machine:

Update-Database –TargetMigration: m1

However, that will only update my local version of the database. For production environment, should I do something like manually delete the migrationhistory record on live or delete the m2.cs migration file generated by entity framework and redeploy the site?

daxu
  • 3,514
  • 5
  • 38
  • 76
  • Just script out the downgrade: Update-Database -Script –TargetMigration: m1 and run that. http://stackoverflow.com/questions/31646488/downgrade-rollback-database-with-code-first-in-production-environment – Steve Greene Jul 08 '16 at 16:26
  • Is that the perferred way to downgrade? but the m2.cs file is still there in the source code, as a result, EF will try to upgrade to the new version (m2) again when it runs? So I think I need to remove that m2.cs file as well? – daxu Jul 08 '16 at 16:29
  • Yes, you can remove it after you generate the script. Script will remove the records from __MigrationHistory back to rollback point. So you can either delete the migration(s) or you could simply correct the mistake with m3 or whatever and apply m2 & m3 consecutively. I prefer removing them. – Steve Greene Jul 08 '16 at 18:06
  • 1
    You say that "i' will update the database to lastest version" - so you use automatic migrations? Then your easiest option is to generate m3 to fix the issues as suggested by @SteveGreene. Or you can change the connection string on your local machine to point to Live, migrate with `-TargetMigration` option, delete e.g. m2 (and generate m3 if needed) and deploy application. – mcs_dodo Jul 16 '16 at 14:32

0 Answers0