8

I have a project that has been a work in progress for several years. It is continually growing and changing. And our data layer project is now 10 times the size of any other project, and takes about 5 minutes to build on a pretty beefy dev box.

What stands out when I take a quick look through the project folders is that the data layer project is using Entity Framework Core, and it has a zillion migration scripts, each of which comes along with what appears to be a snapshot of the database schema in files called MigrationName.designer.cs.

This is very quaint and all, so I can look back to April 2018 (when we made our move to EF Core) and sip a beer with my colleagues as we reminisce about what our schema looked like then, and how very far we've come since then. But seriously, what the heck do we need all these dumb historical .designer.cs files for? Every time we make a migration, it's another 800KB of bloat in the codebase, and while I'm sure it doesn't translate to quite that much in the binaries, it's gotta have some cost. We're sure feeling it every time we have to compile.

Why do we need these files? Can we delete them?

Shaul Behr
  • 36,951
  • 69
  • 249
  • 387
  • Probably this answer could help your to set a new starting point: https://stackoverflow.com/questions/11679385/reset-entity-framework-migrations – Steve Jan 02 '20 at 17:14
  • I assume you have a single consumer of the application? And that consumer is always up to date with the latest migrations? Migrations shine when you have multiple consumers, each of whom are on their own upgrade schedules. As a dev, you don't care that consumer A is on release 10 and wants to upgrade to release 23, because all of those migrations will handle it all for you. – Heretic Monkey Jan 02 '20 at 17:15
  • Could you compress the history to some reasonable point of time in the past? – Kit Jan 02 '20 at 17:16
  • @HereticMonkey we have several environments, all under our own control, which can be running different versions, but no environment should ever be more than a few weeks old. – Shaul Behr Jan 02 '20 at 17:21
  • @Kit So, based on my above comment, yes, we could reasonably assume that no existing environment will need to run migrations prior to, say, 30 days ago. But we may bring up new environments - in fact, we do on a daily basis, since we have CI builds running all the time on different code branches, and those builds create the database by running all migrations. – Shaul Behr Jan 02 '20 at 17:23
  • Then perhaps, as @Kit mentions, you can truncate the migration history at a few weeks prior. My comment was mostly to show that there are use cases beyond your own and those "dumb" files have a purpose. – Heretic Monkey Jan 02 '20 at 17:26
  • I've gone ahead for the sake of experimentation and created a branch in which I delete all the designer files. And...well...it didn't work out so well. As soon as I try access the database, things break. This is very sad. But, at least the compilation took about 3 seconds, and the binary size came down by an order of magnitude, which demonstrates my point, if nothing else, that there's a lot of bloat here. – Shaul Behr Jan 02 '20 at 17:39
  • @HereticMonkey, OK, so how does one truncate the migration history? – Shaul Behr Jan 02 '20 at 17:40
  • 1
    @ShaulBehr try running a clean build of the database from the migrations then export a script of the database (with data to get any seeded data), put that into a single migration and delete everything before it. – Daniel Jan 02 '20 at 19:51
  • @Daniel Good suggestion, but could get ugly if environments that don't have that new init script try to run it. And to my knowledge, there is no way of querying the database in the EF migration script for some telltale signature that will allow me to exit the migration before running anything else...so then the whole migration script will have to be inside one gigantic "if" block? Or is there a better way? – Shaul Behr Jan 05 '20 at 12:47
  • 1
    @ShaulBehr you can insert the record into the ef migrations table for existing environments, so it won't run there. – Daniel Jan 07 '20 at 11:48

0 Answers0