Should EFCore migrations be committed to version control?

Question

Running dotnet ef migrations add XYZ will result in a Migrations directory being created in the project. Should this directory be committed to version control (Git, etc)?

Factory

Yes Of course, if you are using EF Core as Code First Solution, you should definitely save it in your source control – Anchises

@AliKianoor is there a reason for saving it? ie, what does it do? – Factory

The files can be used to change database versions. If you made a migration to add a new table, the same migration can be used to go back and delete this table. – Fossa

Answer 1

Yes, you should commit EFCore migrations to version control.

When a data model change is introduced, EF Core compares the current model against a snapshot of the old model to determine the differences, and generates migration source files; the files can be tracked in your project's source control like any other source file.

Lets assume you're not committing your migrations to version control. And after some time you or one of your team mates make a change to data model then, EFCore will fail to get last snapshot and hence updating database may cause some conflicts/changes which may already exist..!

Lith

Answer 2

You can always recreate migrations yourself using dotnet ef migrations add <name> but that only works for simple operations. If you have complex migrations with custom SQL, or DDL commands that need to run in a specific order then you need to keep the migrations file in VCS to preserve that order.

An example would be creating a computed column. You need to create the table with the first migration, then create another with handwritten SQL to create the SQL function in the second, then a third one migration to introduce the computed column that uses that function. All these operations need to follow an order an cannot be created with a simple dotnet ef migrations ... command

Panslavism

Noting and making it clearer: it is not a choice under those circumstances. It is a MUST. – Hewes

Answer 3

Definitely the migrations should be committed in source control.

Deleting migrations will make it impossible for EF to generate future migrations for future changes to an existing database.

Also, if you did the following...

1. Add a migration
2. Execute the migration, creating a new table
3. Then delete the generated migration code
4. Add a new migration with the same table name
5. Execute again the migrations

Here EF will fail since the underlying table already exists and the migration created from #4 will be a 'create' statement instead of an update statement.

Coprology

Yes and no. Deleting the migrations won't have an immediate effect, as adding new migrations is solely based on the snapshot file. However, you won't be able to roll back changes (dotnet ef migrations remove --force) since the migrations Down() method will be called on rollback/removing an migration to bring the database on its previous state. Also without the migration files you can't do automatic migrations via context.Database.MigrateAsync() since the migration classes won't be compiled into the binary – Grimbald

Answer 4

Maybe, when doing a major release it's also a good idea to make a release specific copy of the snapshot file, that way, migrations can be bundled as per release, since one can do a new migration based on the snapshot of the last release

Everywhere