0

I've been working in a project the last 4 years. At this moment we have 2,510 migrations and it's expected continuea adding more and more while the system becomes more sophisticated and new features are added.

Is a good/bad practice to have this quantity of migrations?

We are discussing the option to delete all the migrations and create a new one representing the whole DB, but we don't know this is a good practice. Does anybody have experience doing this kind of stuff?

FredE
  • 71
  • 7

2 Answers2

1

If you can rebuild from scratch then there is nothing bad about having an excessive amount of migrations. In a working production environment, migrations really are only just a way to get a dev machine up and running, or to roll back a bad release etc.

However, I personally like to reset the migrations every now and again. We have the same problem, 1000s of migrations and due to human error with commits, and namespace changes (insert reason here) it's unlikely over extended amounts of time it would rebuild.

In fact, with production it would never be rebuilt anyway, it's only for dev test machines.

There are some very significant down sides risks though, If you have custom code and scripts in your UPs to do various things (which you likely do) then you will have to be careful and add them back, and also backup everything!

Disclaimer, I do not promote anyone to do this unless they know exactly what they are doing. Having lots of migrations are fine and does not cause a problem in any normal circumstance, however screwing up a production database can cost a lot.

Further reading

If you want to go through with this

halfer
  • 19,824
  • 17
  • 99
  • 186
TheGeneral
  • 79,002
  • 9
  • 103
  • 141
1

In my view the risks of collapsing_migrations of not_collapsing_migrations.

C - Collapsing migrations

Risks:

  • C_R1 - Result database is not what it should be, because:
    • custom changes in individual migrations are lost when creating the summary migration
    • other reasons
  • C_R2 - Deployment risk: not trivial deployment (includes modifying migration_history table)

Benefits:

  • C_B1 - Faster start-up for code which recreates db (how much faster?)
  • C_B2 - Cleaner solution
  • C_B3 - The current migrations contain operations deprecated on new db releases
  • C_B4 - (I don't recommend this, see below) If the initial done using a newer version EF, the new version of EF may created better SQL, potentially even fix bugs, or highlight issues.

NC - Not collapsing migrations

  • NC_R3 - Migrations reach a limit - high impact, unlikely, should be detected prior to PROD

Anyway... let's do this

I don't recommend it, but if you decided to collapse migrations here are two approaches that can reduce risk C_R1 (result db != current db, because some custom code was 'lost in translation').

A. Use an external tool to create the initial script that represents the db and use the generated sql as the basis of the first new migration (as opposed to just running Add-Migration and using the code that EF came up with).

B. Make the initial migration contain the code from all migrations (as opposed to just running Add-Migration and using the code that EF came up with).

tymtam
  • 31,798
  • 8
  • 86
  • 126