Reputation: 914
We are developing a large ASP MVC web application EF6 Code First (100+ entities) and we have some doubts about migrations.
If we enable migrations while we are developing but not yet in production, we are going to end up with tons of migration files, since it is recommendable to do small migrations. Is this a correct approach or we should enable DropCreateIfModelChanges for developing before the app is in any client?
Also, we need to seed the database with common data all the clients using the app are going to need, like countries, states, a few super users... Where do we have to seed this data so it is always in every client we install the web app?
I have seen a few different approaches: - Seed data in the Seed function of Migrations Configuration, with a AddOrUpdate command, but I have seen in some places that this is a bad approach. - Seed data in a Add-Migration using Sql("INSERT INTO....");
Thanks in advance.
Upvotes: 0
Views: 224
Reputation: 12324
I usually start development just using the initializers. There is a seed method specifically for initializers that only runs when the database is created which is ideal for security and lookup tables. (Migration initializers run with every update-database).
When I get to the point where I don't want to lose other data, I switch to migrations. As you mention, these can accumulate so I use Chris's technique to roll them up before deployment.
You should also be aware of the issues working with migrations in a team environment.
Upvotes: 0