Code First Migrations: August 2011 CTP Released

  • Article

 

The information in this post is out of date.

Visit msdn.com/data/ef for the latest information on current and past releases of EF.

For Code First Migrations see https://msdn.com/data/jj591621

 

Back in April we announced the release of Entity Framework 4.1 (EF 4.1). The most consistent request we have heard from you since releasing EF 4.1 has been for a migrations solution for Code First that will incrementally evolve the database schema as you model changes over time. Today we are announcing the release of our first Community Technical Preview (CTP) of our Code First Migrations work.

This initial CTP is primarily focused on the developer experience inside of Visual Studio. We realize this isn’t the only area in which migrations is important and our team is also working on scenarios including team build, deployment and invoking migrations from outside of Visual Studio as well as from custom code.

You may be wondering why we are releasing the ‘August 2011 CTP’ in July 2011… we were so eager to get the release in your hands we ended up shipping early!

 

Getting Started

The migrations walkthrough gives an overview of these commands and how to use them for development.

This initial CTP is available via NuGet as the EntityFramework.SqlMigrations package.

Once installed, a number of additional migrations commands are available in the Package Manager Console inside of Visual Studio.

 

Prerequisites & Incompatibilities

Migrations is dependent on EF 4.1 Update 1, this updated release of EF 4.1 will be automatically installed when you install the EntityFramework.SqlMigrations package.

Important: If you have previously run the EF 4.1 stand alone installer you will need to upgrade or remove the installation before using migrations. This is required because the installer adds the EF 4.1 assembly to the Global Assembly Cache (GAC) causing the original RTM version to be used at runtime rather than Update 1.

This release is incompatible with “Microsoft Data Services, Entity Framework, and SQL Server Tools for Data Framework June 2011 CTP”.

 

Issues & Limitations

We really wanted to get your feedback early in the release cycle so this CTP hasn’t been polished and isn’t a complete set of the features we intend to ship.

Some known issues, limitations and ‘yet to be implemented’ features include:

Please read this list before using migrations as there are some important limitations of this initial CTP.

  • There is no provider model, this release only targets SQL Server, including SQL Azure. SQL Compact and other providers are not supported. We are currently working through what the provider model should look like for migrations.
  • All existing tables will be re-built during first migration. The components we are using for schema comparison are overly sensitive to things such as ANSI_PADDING. This often results in tables being rebuilt when you swap to using migrations to maintain the schema. We are working on removing this behavior.
  • Extra database constructs, such as indexes, can not be added in custom scripts. If you add an index in a custom script it will be removed by the next automatic upgrade. This is a limitation of this first CTP and we intend to change this behavior.
  • Migrations is overly sensitive to column ordering and will re-build a table to insert a column in the correct order. We intend to make this behavior customizable.
  • The custom scripts that migrations scaffolds are verbose and include a lot of additional SQL that is not required. We are working to tidy these up so that they only include the core commands.
  • Migrations currently needs to run in full trust. This isn’t an issue when working inside of Visual Studio but if consuming the migrations assembly from custom code you may want to run in medium trust. We are looking at ways to support this in a later release.
  • This release is only available via NuGet. As we support more scenarios such as team build and an ‘outside of Visual Studio’ command line experience we will also support more installation options.
  • There is a known issue that may result in a “The project '<project name>' does not contain or reference any contexts.” error message. This issue occurs when your context is defined in a referenced project and NuGet's Package Manager Console (PMC) is initialized before your solution is loaded. If you encounter this behavior, close PMC and restart Visual Studio taking care not to reopen PMC until after your solution has loaded.
  • The performance of migrations is not ideal in this preview and we are working to improve performance for upcoming releases.
  • Previewing changes via the ‘–Script’ option only works after the schema has been upgraded at least once using migrations. If you haven’t used migrations on the database you will just get a create script for the entire database when using ‘-Script’.
  • Downgrade is currently not supported. When generating custom scripts you will notice that the script is named ‘Up.sql’ but there is no corresponding ‘Down.sql’. We are planning to add downgrade functionality prior to RTM but it is not available in this release.

 

Support

This is a preview of features that will be available in future releases and is designed to allow you to provide feedback on the design of these features. It is not intended or licensed for use in production. If you need assistance we have an Entity Framework Pre-Release Forum.

 

Feedback

We really want your feedback on this work so please download it, use it and let us know what you like and what you would like to see change. You can provide feedback by commenting on this blog post.

ADO.NET Entity Framework Team

License.rtf

Comments

  • Anonymous
    July 28, 2011
    "Migrations is dependent on EF 4.1 Update 1, this updated release of EF 4.1 will be automatically installed when you install the EntityFramework.SqlMigrations package." Does not compute. Do you mean 4.1.1 or something like that?

  • Anonymous
    July 29, 2011
    @Mike, see the post titled "EF4.1 Update 1 Released" on this blog for more informaion. From the post, "[EF 4.1 Update 1] is a refresh of the EF 4.1 release that includes a small number of bug fixes and some new types to support the upcoming migrations preview."

  • Anonymous
    July 29, 2011
    @Mike Just to add to what Brice said, "EF 4.1 Update 1" is effectively EF 4.1.1, we've heard strong feedback that our release names etc. are confusing and are working out how we fix that in the future.

  • Anonymous
    July 31, 2011
    SQL Migrations is something I've been waiting for. However in its current shape I dont see it useful for real life production scenarios. This is why:

  1. DB schema needs to be versioned. When a deployment guy goes to a site, he should not need to know which sql patches to apply - the tool should figure it out by itself. I'd normally use a special table for that but you can do it in other ways
  2. There should be an option to make a db backup built in the migration framework
  3. It should be well integrated with msbuild (again with version detection and applying selected patches only, perhaps like schema compare in VS?)
  4. It should be accompanied by a tool (could be a jscript even) that you can copy with sql and patch a db schema) these are most important points for me now, I will elaborate when they get attention in next version of SQL migration... :) Keep up the good work!

  • Anonymous
    August 10, 2011
    I would love something like this for edmx-based solutions (i.e. non-code-first). If it could compare my new edmx file to my old edmx file and generate the change script, that would be very helpful.

  • Anonymous
    August 24, 2011
    SQL Migration is a great step forward in what is often a very messy and handheld part of delivering software upgrades.  In an Azure based application which could contain many instances of roles, the upgrade process takes a significant amount of time this often results in scheduling downtime for application upgrades.  SQL Federation may also introduce issues around large scale rollouts and dataschema updates. I would see this working by annotating the data classes with the changes (this could also provide a richer and more automated way of handling name changes and data transformations) and the EntityFramework resolving the differences between two versions of the database. [Migration PreviousName="Person"] public class Author {    [Migration Depreciated=true]    public string FullName { get; set; } // This is an old column I want to replace with firstname/LastName   [Migration Default=delegate() { ... }]  // Delegate should contain function to parse to first space in fullname    public string FirstName { get; set; }    public string LastName { get; set; }   [Migration Default=DateTime.Parse("01 Jan 1980")]    public DateTime FirstName { get; set; }  // This is a new column   public string email { get; set; } }

  • Anonymous
    August 25, 2011
    I have to ask, why isn't this being done as a part of SQL Server rather than EF?  What does EF do so that is so special to the upgrade?  Isn't it really just a SQL Server solution anyway?  Do you expect to be able to handle all database vendors with this EF solution for upgrade?  If not, then move this to SQL Server land, or better yet to ADO.Net so it does work with all providers (even if they don't have an EF provider). This has got to be the #1 database problem in the world, changing of schema over product lifespan.  Yet I see a modeling framework solving the problem. Seems odd to me.

  • Anonymous
    September 07, 2011
    @KD –Your first point is handled by the __MigrationsHistory system table in the latest preview (Alpha 2). Points 2 & 4 are great feedback, thank you! Point 3 is definitely on our backlog to handle in a future release. @e-labs – This migrations experience is very targeted towards Code First, even more so in the latest preview where migration scripts are expressed in code. For the EDMX/Designer based approach take a look at Juneau/EF integration - channel9.msdn.com/.../DEV314 @Philip Coupar - BlackSnow –  This is a very interesting problem, it’s not something we are trying to solve in this initial release but it is ‘on our radar’. @Jason Short – This migrations effort is very tied to Code First. Migrations are calculated based on changes to your Code First model and expressed in a code format that is similar to other areas of the Code First API. It’s also restricted to concepts that can be expressed in Code First (currently only tables, columns, primary keys and foreign keys). The latest preview also includes a provider model so that other database providers can work with migrations. The Juneau product is targeted at database versioning for SQL Server: msdn.microsoft.com/.../hh394146.aspx