Seed Data

[bricelam]

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: New feature topic: Data Seeding EntityFramework.Docs#509
• Add support for navigation seeding: Data Seeding: Add support for navigations #10000
• Add EntityTypeBuilder.SeedData sugar that takes an entity and a property bag for shadow properties: Data Seeding: Add sugar for shadow properties #9999
• Perf: batch the operations: Data Seeding: Batch the operations #9997
• Perf: skip optimistic concurrency checks: Data Seeding: Generate leaner SQL #9998

[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.

[rowanmiller]

BTW if we do Seed.cs we'll probably want something like the AddOrUpdate method. If so, we should consider the ability to whitelist properties to be updated, as discussed in #453.

[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]

@giggio Totally agree, having some sort of first class data manipulation API would be great. This issue is specifically about expressing some seed data in terms of the current model, but your scenario would also be very good to enable. The data migration would need to be weakly typed rather than using the model (since the model will change over time).

[hbopuri]

How is Seed method handled in EF7?

protected override void Seed(MyContext context){}

[rowanmiller]

@hbopuri - There isn't a first class API for this at the moment (though this work item is tracking adding one in the future). Currently you would just write code in app startup to handle seed data.

[hbopuri]

@rowanmiller wasn't override seed part of earlier EF versions? is EF7 a upgraded version of earlier versions or a completely newly designed from scratch?

HaBo Rocks
Harsha Bopuri

[rowanmiller]

@hbopuri - It's a major version and has breaking changes in it. These breaking changes are larger than we would typically do in a release, but you can read more about the reasoning behind what we are doing here http://blogs.msdn.com/b/adonet/archive/2014/10/27/ef7-v1-or-v7.aspx.

[heathyates]

@rowanmiller Will this feature ship with the RTM? And totally agree with @giggio suggestion.

[rowanmiller]

@heathyates - Not sure if we'll get a seed method equivalent into initial RTM. It is super easy to write the logic in your app start code in the meantime.

[jwdavidson]

@rowanmiller - It is easy to write a seed method using the app startup code. However, all the samples that I could find incorrectly use EnsureCreatedAsync and as a result fail to load the seed data. What is missing is a way to determine if the DbContext is correctly configured and has the model applied that matches the seed data requirement. This could be solved by having a way to detect if a particular Migration has been applied to the datastore.

[heathyates]

@jwdavidson I have not experienced a failure to load the seed data and I use EnsureCreatedAsync. Has the mvc music store failed for you? I'm not implying I don't believe you or your claim, but confused as to what samples are not working for you? Would be interested in duplicating what you have observed myself. :-)

[rowanmiller]

@jwdavidson do you want to apply migrations during startup to ensure the database is up to date? If so, context.Database.AsRelational().ApplyMigraions() is the API to do this.

[jwdavidson]

@heathyates - The case where EnsureCreatedAsync is when it returns true, which it does when the database was not previously created and/or the initial migration has not be loaded to the database. After that if you want to load seed data which uses a second migration then it will fail as EnsureCreatedAsync will return false.

@rowanmiller - the suggested ApplyMigrations() process may enable the seed function to be reliably processed from the startup code. I will try that tomorrow and let you know.

[jwdavidson]

@rowanmiller - the following code block seems to do exactly what I want: ensure the database exists and the relevant migrations have been applied

using (DbContext db = (DbContext)serviceProvider.GetService<ApplicationDbContext>()) {
    if (!db.Database.AsRelational().Exists()) {
        db.Database.AsRelational().Create();
    }
    db.Database.AsRelational().ApplyMigrations();
}

After this any data insertion routines may be safely added. Thanks.

[rowanmiller]

@jwdavidson you should be able to remove the existence check and creation. ApplyMigrations() will take care of creating the database if it doesn't exist.

using (DbContext db = (DbContext)serviceProvider.GetService<ApplicationDbContext>()) {
    Database.AsRelational().ApplyMigrations();
}

[jwdavidson]

@rowanmiller - Yes, that works as advertised, just not used to doing something like this without an "if" validation. Thanks again

[rowanmiller]

@weitzhandler good discussion on the best pattern for the moment going on at #3070

[divega]

Clearing the milestone after talking about this with @DamianEdwards and @rowanmiller. It is really hard to find the right place to do seeding, in particular in an ASP.NET application. We should at least consider trying to have a solution for RTM.

[ToddThomson]

I'm a bit late to the party, but I wanted to give the EF Core team input on my requirements for seeding or DbContext data initialization. Perhaps entity SeedData could be made to work for me, but I can't wait for release 2.1.
I feel that the APIs for DbContext data initialization should be added to DbContext. A simple

DbContext.MigrateToLatestVersion( IDbContextInitializer initializerClass, IServiceProvider serviceProvider ) 

which utilizes DbContext.Database.Migrate() and after which calls the seed( dbContext, serviceProvider ) method in the initializer class.

The DbContextInitializer class then has full reign to manipulate the context and persist changes to the repository.

Reading through this issue, this looks like the initial solution proposed by @rowanmiller . It's simple and easy to implement.