Efcore: Squash migrations

[rowanmiller]

It would be good to have the ability to squash several migrations into a single file to help reduce the number of files in a project.

We probably want to keep track of the original list of migration names so that we can reason about this when targeting an existing database that the original migrations were applied to in their un-squashed form.

[popcatalin81]

@rowanmiller how will squash work? Merge Migrations into one or simply place them in a single file.

I think merging will be problematic when a target database has partial migrations but not all from a squash.

[bricelam]

@popcatalin81 I suspect at first, it will simpy concatenate all the operations together into one migration. In the future, it may try and simplify the operations (e.g. renaming A -> B -> C will become just A -> C)

Correct, "rewriting history" is always a bad idea. Before squashing, you'll have to revert all the migrations you want to squash, squash them, then re-apply the new one. You shouldn't do it if the migrations have been applied on any database other than your local one.

This operation would be useful while developing a new feature. You could add all the migrations locally you want, but before merging your feature, you could squash them all down into a single migration.

[TheMadKow]

:+1: For this idea

[markusvt]

I just wanted to suggest that idea also.. the migrations folder gets quite large quite fast if the projects develops over time

[dario-hd]

I was wondering if removing them all and creating an "initial migration" would be a better approach. In the end this is what I did recently. Of course the "initial migration" should be executed only on database creation. This will not only reduce the number of files in the project but it will also speed up the initial database creation if you recreate it multiple times e.g. for development and testing purposes. What do you guys think? @rowanmiller @bricelam

[pgrm]

I'm puzzled that this issue is so inactive. How are others solving the issue of the ever growing Migrations folder?

Could there be at least some best practice described in the documentation @AndriySvyryd ?

[bricelam]

@pgrm I briefly mentioned a strategy in the Migrations docs I'm adding...

[replaysMike]

This is a common problem we run into every once in a while. It's quite simple to accomplish. If your database is already up to date just delete all the migration files and truncate the dbo.__EFMigrationsHistory table. Generate a new initial create migration and you have now squashed all your migrations. You lose any comments but that's minor if you're needing to do it.

[PMExtra]

@replaysMike It will lost my custom migration operations. (For example, I set a custom default value for a new field.)

[replaysMike]

@PMExtra that’s surprising since you’re basically creating a migration based on the current state of the database. Is the default value being applied at the db level, or code level when the entity is created?

[deanvr]

Is this still open or closed? We often end up with way too many migration files in VS solution explorer, to resolve this its a pain in the... we manually run the migrations on a clean database, take the schema and data inserts and extract those and literally create a new migration that becomes the new seed, this way we don’t loose history and don’t have to truncate the migration table. What would be really cool is if we had a command that would reverse engineer a seed migration from a given database , this would save us a couple hours every month or so. Thank you - let’s make this happen!!!!!

Btw database snapshots is a little overkill?? Might have some interesting application though??? I’m thinking integration testing?

[snebjorn]

I usually manually "squash" migrations into new InitialCreate when a new system goes into production, removing all the develop time migrations as they usually aren't very helpful to reason about model changes.

But changes to the model after the system is in production are very important.

I don't think the squashed migration should just be a concatenation of the existing migrations, as one might add a column/table and another might remove it again, it's just noise. It should be a fresh InitialCreate migration. Nice, clean and ready to run on the production environment without any develop time noise.

But this is already possible today, with possible data lose on the existing DEV environments.

I'd welcome a squash feature to make this easier and avoid data lose.

[roji]

@snebjorn if your goal is to squash development-time migrations which haven't yet been applied to production, it's pretty easy to simply reset your Migrations folder and then generate a single new one, which would contain all the changes - you can do that before merging your change.

[yakeer]

Any plans to automate this in any release?
The manual squashing is really frustrating.
And at some point, Azure DevOps is failing due to huge migrations dll.

[ajcvickers]

@yakeer This issue is open and on the backlog, which means that we do intend to implement this in a future release. See release planning for more details.

[clement911]

The latest VS release is extremely slow to compile migrations for example so this squashing might help.
See https://developercommunity.visualstudio.com/content/problem/1253845/visual-studio-2019-version-1680-very-slow-to-build.html

[roji]

@clement911 that issue should hopefully get resolved really soon on the VS side, so shouldn't require waiting for migration squashing in EF.

[RCTycooner]

@clement911 same issue here... going to attempt to manually squash my migrations now.

[clement911]

@RCTycooner this was fixed in the latest VS release 16.8.2

[RCTycooner]

@clement911 what's the status of issue for build pipelines? We're using hosted agents that should be getting the latest versions of everything, but still has this issue. Will update my VS to 16.8.2 and try a local build anyway