Seed Data

In EF6, this was accomplished using DbMigrationsConfiguration.Seed(), but migrations configurations don’t exist in EF7.

• Add EntityTypeBuilder.SeedData
• Add support for shared table seeding
• Add support for owned types seeding
• Add seed data validation
• Reuse existing code by delegating to IStateManager, IEntityMaterializerSource and SharedTableEntryMap
• Documentation: https://github.com/aspnet/EntityFramework.Docs/issues/509
• Add support for navigation seeding: https://github.com/aspnet/EntityFrameworkCore/issues/10000
• Add EntityTypeBuilder.SeedData sugar that takes an entity and a property bag for shadow properties: https://github.com/aspnet/EntityFrameworkCore/issues/9999
• Perf: batch the operations: https://github.com/aspnet/EntityFrameworkCore/issues/9997
• Perf: skip optimistic concurrency checks: https://github.com/aspnet/EntityFrameworkCore/issues/9998

[giggio]

We should be able to add data along with a specific migration. For example, I add a new table and then add some data to it right after the table is created. This is really important for domain data, that mainly changes when some app structure changes. An example is menu records, where I mostly only add a new menu record when I add a new feature. So, it would be great to have some methods to add/change data on the MigrationBuilder class.

[rowanmiller]

Proposal is to have a Seed.cs file in the Migrations directory (alongside model snapshot etc.). We could scaffold this when the first migration is added:

public class BloggingContextSeedData : DatabaseSeedData<BloggingContext>
{
    public override void Seed(BloggingContext context)
    { 
    }
}

This is essentially the same as the Seed method on EF6.x. While this approach has it’s issues it seems to work pretty well and we haven’t heard a lot of complaints.

We could also look at some simple Insert/Update/Delete APIs in Migrations. This would give folks a more advanced option that overcomes some of the limitations of Seed():

• Removes the need to write AddOrUpdate code since the data is inserted once during the migration (and presumably deleted during the down).
• Removes the need to update the Seed code whenever the model changes (since it is applied at a well known point in time of the schema.

Of course, data in migrations would be loosely typed since it wouldn’t use the current model.