Entity Framework Code First Migrations

Quickly learn about how EF handles schema migration in Entity Framework Code First Migrations.

Personal notes follow.

Notes

1 Introduction and Automated Migrations

  • To modify the database without destroying its contents
    • Modification keeps schema in-line with the model and its changes
  • Steps stated in code, and those steps are the “migration”
  • Many migrations will exist over time
  • Migrations are first-class things in EF
  • Initializer: MigrateDatabaseToLatestVersion
  • Automated or manual “code-based” migrations
  • EF includes CommandLets
    • Open Package Manager Console
    • Set correct project
    • Run enable-migrations
    • Creates first manual migration
  • Automatic migrations might be just fine
    • AutomaticMigrationDataLossAllowed = true
  • context.DataBase.Initialize unnecessary when you actually do anything else
  • Migrations will create an initial migration for you if it is enabled when EF
    creates the database for you that first time
  • When you have an existing database
    • Missing auto-gen’d initial migrations and history table
    • Must tell EF to do it
    • PowerShell, add-migration name
    • Creates your first using only model data
    • Decision must be made as to what your startup does
    • Can -IgnoreChanges
    • update-database adds migration history table to the db
    • Now you can switch to automatic migrations
    • This reflects a workflow that lets you build a database iteratively and when
      are ready switch to migrations however you want

2 Code-Based Migrations

  • Automatic migrations is forward-only; you may want to be able to go back
  • Add-Migration and Update-Database are cool, and hand-coded are cooler
  • Update-Database can run downwards, too
  • Accidentally said “Scaffolding” lol
  • Set AutomaticMigrationsEnabled=false to use code-based migrations
  • You can tell Update-Database what project to run under
    • get-help update-database -detailed
  • You can do all this stuff right in powershell
  • DbMigration has lots of goodness
  • “Data Motion”, setting a default value for existing rows
  • Migrations allow raw SQL execution
  • Each Migration can seed the database
  • Update-Database -script is how you define a work-flow to go between local dev
    with auto migrations AND pushing out to production

    • -sourcemigration:”foo” to see changes since that migration spec
  • Disable migrations on your production box using a config setting
    • Database.SetInitializer<FooContext>(Null);
    • App.config
      • EntityFramwork:contexts:context
        • disableDatabaseInitialization“true”=
    • This is another flow, the prod App.config disables it, and in dev/prod,
      enable it
  • DbMigrator lets you programattically execute migrations
    • Can only target a particular migration
    • Looks at the startup project to get the connection string in the config
      because the API is so limited here
    • MigratorScriptingDecorator
    • Why even use this?

Leave a Reply

Your email address will not be published. Required fields are marked *