3

I recently started a small test app using EF 6 Code First so that I can learn / practice using EF and databases (I'm a front end developer).

As I am developing I will want to make changes the POCO objects that I'm generating the entities from. Using "Add-Migration" will create a new Migration with these changes, but my "Migrations" folder quickly becomes a mess with many Migrations.

I would like to segregate my migrations, where each migration adds one of the models.

Is there a good way to organize Migrations by the model they are updating? I can't seem to find a way to run the "Down" function of a specific Migration. You can use "Update-Database -TargetMigration: MigrationName", but that will undo everything that came after that. Or should I not worry about having many migrations and that is to be expected with code first?

I understand this would not be practical if this were a production app because you would lose data.

Perhaps I am fundamentally misunderstanding code first migrations as well, and should stick with Automatic Migrations while the project is in development.

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
King Arthur
  • 131
  • 2
  • Organizing migrations in this way seems at odds with the purpose of migrations, which is to "modernize" your schema with the latest group of development changes. Seldom do developers work on a single "model," and fragmenting your migrations in this manner will only complicate things, not simplify them. – Robert Harvey Feb 14 '15 at 19:20
  • Thanks for the response - so typically, it is expected to have a single migrations folder with many migrations? I am probably fundamentally misunderstanding this. – King Arthur Feb 17 '15 at 13:46

0 Answers0