5

I am using Entity Framework Code First and I would like to generate C# code for seeding data from data that already exists in the database. Right now, populating DropCreateDatabaseIfModelChanges.Seed() seems to be a completely manual process where the developer creates the objects and fills in the values. This is somewhat manageable if developers are the only ones that are responsible for seeding the data, but I'd imagine that this is often not the case.

In my particular case, there are non-developers that help populate the database through the use of some MVCScaffolding generated input forms. The data that they add really does fall into the "seed data" category so I want to include their newly added rows into my Seed() implementation. One could simply interpret this as a "Generate C# code INSERT script" function.

Thanks!

charlie
  • 4,612
  • 1
  • 22
  • 18
  • 2
    Have you considered having Sql Server extract a data generation script from all your tables, and run that SQL script whenever you need to seed a new database? You could automate this as well, run it from C# in a unit test or whatever you need. Not as clean as auto-generated C# code, but it is quicker and easy to repeat. Here's how to do it: http://stackoverflow.com/a/1316313/1373170 – Pablo Romeo Aug 26 '12 at 20:34
  • Hey Pablo. Thanks for the suggestion and this is actually what I currently do as a workaround. Using the "Generate Scripts" command with the option of exporting the "Data Only" works pretty well and checking in the script into source control is great for comparisons and saving revisions. The only problem I have is that this goes against the Code First paradigm and adding a new property to an entity results in a very painful manual edit of the script file. I'll vote your answer up though because it's definitely one of the best alternative solutions so far. – charlie Aug 27 '12 at 05:12
  • Why do you keep dropping the db and repopulating? Couldn't you just use EF migrations? Then you generally won't need to reared? – GraemeMiller Mar 28 '15 at 15:30
  • For production, it totally makes sense to not drop the db and repopulate. However, for development and test environments, it's useful to have a baseline set of data where automated tests can be run against in a consistent manner. Over time, the data can become pretty inconsistent with orphaned rows and non-existent weak relations. Also, having a set of baseline data that can be easily rebuilt is great when multiple developers are running various experiments with the schema and that can all instantiate a local copy of the database. – charlie Apr 21 '15 at 23:14

2 Answers2

0

The best solution that I've come with for dealing with this can be seen here: https://stackoverflow.com/a/29785119/277992

It's not generating C# code, but I can rapidly seed data into a newly created database. I can update the seed data using SSMS "Edit Data" functionality and then regenerate another INSERT script.

Community
  • 1
  • 1
charlie
  • 4,612
  • 1
  • 22
  • 18
0

You could just generate an sql script and then run that inside your seed method:

var sql = System.IO.File.ReadAllText("SqlScript.sql");
_context.Database.ExecuteSqlCommand(sql);

And in case I want to have data seeded during migration updates:

public override void Up()
{
       SqlFile(@"migrationscripts/cities/insert-cities.sql");
}
        
public override void Down()
{
       SqlFile(@"migrationscripts/cities/delete-cities.sql");
}
WtFudgE
  • 5,080
  • 7
  • 47
  • 59