Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>My recommendation on cases like yours, that you have data that affects the migration success, is to do it inside the migration.</p> <p>I do it all the time, creating sql scripts to be runned inside the migration's Up method, and down method. That way when the migration applies succesfully you know it is consistent with the data also. Plus, you can undo the migration, undoing at the same time all the data.</p> <p>The downside of this approach is that you can't use EF's context to create data, forcing you to create Sql methods that run your hand-crafted sentences.</p> <pre><code>public class TestMigration() : DbMigration { protected override Up() { //Do some migration stuff Sql("INSERT YOUR DATA HERE"); } protected override Down() { //Undo some migration stuff Sql("DELETE YOUR DATA HERE"); } } </code></pre> <p>If you still want to go with the Seed method aprroach, I didn't try it by myself, but I think this could work:</p> <pre><code>internal sealed class Configuration : DbMigrationsConfiguration&lt;TheContext&gt; { protected override void Seed(TheContext context) { //Set a bunch of entities using (var transaction = new TransactionScope()) { try { context.SaveChanges(); transaction.Complete(); } catch (Exception ex) { var migrator = new DbMigrator(this); var lastMigration = migrator.GetDatabaseMigrations().Last(); migrator.Update(lastMigration); } } } </code></pre> <p>The problem I can see with this code is that, after running the Update method, the Seed method will trigger again, creating an infinite loop.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload