1

Closed

EF5 Migrations - Multiple Developers

description

We have an issue where the following occurs when using code first and scaffolded migrations.

1 - Developer A adds class ClassA and scaffolds the migration
2 - Developer B adds class ClassB and scaffolds the migration (without having developer A's changes as they have yet to be added to source control)
3 - Developer A commits to source control and updates to top copy
4 - Developer B commits to source control and updates to top copy

We now have the following problem:
1 - Developer A is now being told that "Unable to update database to match the current model because there are pending changes and automatic migration is disabled."
2 - Developer B is missing the table that Developer A added and migrations thinks he is up to date.

The reason is because the model is stored with the migration and the later migration was created without having Developer A's model changes. If Developer A now does Add-Migration he will get a new migration with the same changes in as he previously created!

This seems quite a fundamental issue in a multi-developer environment.

Cheers
Chris
Closed Jan 16, 2013 at 11:58 PM by RoMiller

comments

AndrewPeters wrote Jan 2, 2013 at 10:48 PM

Hi Chris,

This can typically be handled by using the "re-scaffolding" feature, which is a way of updating the code-behind metadata of an existing migration. The way you re-scaffold is by running Add-Migration and passing the name of an existing migration. Migrations will then overwrite the code-behind metadata with the latest model.

Here's how it would work for the scenario you describe:

1 - Developer A adds and runs migration A locally.
2 - Developer B adds and runs migration B locally.
3 - Developer A commits to source control.
4 - Developer B is ready to commit and so gets latest from the repo.
5 - Developer B sees that a new, earlier migration (migration A) now exists and so migration B needs to be re-scaffolded.
6- Developer B reverts migration B locally by using the TargetMigration argument and pointing to the local migration occurring before migration B (or $InitialDatabase to undo all applied migrations). NB. This step is only required if developer B has actually applied migration B.
7) Developer B re-scaffolds migration B and runs Update-Database - Migrations A & B are applied.
8) Developer B commits. Migration B now has the correct metadata and so developer A is able to simply pull and run Update-Database.

Cheers,

Andrew.

glennc wrote Jan 3, 2013 at 10:18 PM

Consider for EF6

RoMiller wrote Jan 16, 2013 at 11:58 PM