2

We're just starting off with using Entity Framework Code First approach and I'm playing with the Code Migrations system.

So we were wondering, are the migration files intended to be treated as generated code and shouldn't be modified or are they supposed to be generated for you as a scaffold and then you can add extra things like default values and extra data to it?

Just because starting off it seems like it is quite easy to have your database get out of sync if a migration was done incorrectly and the Down() methods doesn't necessarily clean up the Up method. And the problem is you can't really know whether it works until you actually need to reverse the migration.

In addition, should migrations ever be changed, deleted or re-scaffold-ed if they've been checked in and definitely if it's been elevated to an upper level environment? Because I can see Team Member A checks in a migration, then Team Member B checks it out and runs it, if Team Member A modifies it now, then they both would have different versions of the databases and there may not be an easy way to reverse it as the migration files have all changed.

It seems Code Migrations seem like a powerful technology but there are situations where databases can get out of sync with the migration process and therefore it seems in a team requirement, there needs to be some rules in place.

What are the best practices to ensure that Code Migrations work well in a team environment?

2
  • I personally don't think code migrations should be under source control. Your CI server should handle them, if you have one. Source control contains the SQL scripts for the database changes. If code-first means "we don't do SQL scripts," then I guess your stuck. Your best practice is going to be "don't allow a bogus migration to be released to the public, and if you do, provide a new migration that fixes or reverses it." – Robert Harvey Mar 15 '17 at 23:11
  • I played around with EF migrations after having used ActiveRecord for Ruby for quite a while. I have to say, nothing beats straight SQL. Ditch the migrations and learn SQL. After all, that's where your data is stored. – Greg Burghardt Mar 16 '17 at 1:31
2

So we were wondering, are the migration files intended to be treated as generated code and shouldn't be modified or are they supposed to be generated for you as a scaffold and then you can add extra things like default values and extra data to it?

The add-migration literally says it's scaffolding the class for you. You can certainly go in and add things, though extra data is better done via the Seeding stuff available in the DbContext Configuration.

In general though, I would never modify them once checked in. And I wouldn't really count on them being reversible if you modify them at all. If you screw up, and need to make a fix then you get to make a new migration to do that.

From what I've seen, they're best treated as one-way modification scripts that EF will nicely order and optionally execute for you.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.