Share via

Code First Migrations: Your Feedback

  • 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

 

We recently released the first preview of our migrations story for Code First development; Code First Migrations August 2011 CTP. We released this preview early in the development cycle because we want your feedback so that we can use it to shape the product. We’ve received a heap of feedback and this post will summarize the feedback and how it is changing the product.

Our team is currently working on the next preview, which will include the changes discussed in this post. We want to keep the time between releases minimal and are aiming to have the new preview out soon.

The main points of feedback and resulting changes are:

  • Migration scripts should be expressed in code (not SQL): This was the most consistent and resounding bit of feedback we heard. We are working on replacing the SQL scripts with a code based alternative and this will be included in the next preview.
  • Provider model is a must: We will be including the provider model in the next preview.
  • Automatic migrations is just too much magic: The ‘August 2011 CTP’ actually included the ability to do automatic migrations, imperative migrations (similar workflow to existing solutions), or a combination of both. However, the lack of a provider model and a code based way of expressing scripts meant the imperative experience was below par compared to existing solutions. We also focused on the automatic and mixed-mode approach in our walkthrough. For the next release we will start with the imperative approach and then delve into how automatic migrations can optionally be used to avoid having large amounts of code in your project for simple changes. The existing imperative experience is described in this post.
  • Named versions are a must: The ‘August 2011 CTP’ actually included the equivalent of named versions but the above points made the mental model hard to grasp. What we were referring to as a ‘custom script’ is equivalent to a named version and future releases will support migrating up/down to any given point. For folks choosing to go with the automatic migrations you still have the option of inserting a named version at any time, this would effectively be an empty script.
  • Need a better deployment story: The ‘August 2011 CTP’ was aimed at the developer experience and didn’t include any of the work we plan to do around team build, deployment etc. We’ll put together some more details on what we plan to deliver for these scenarios and share them with you.
  • General comments about syntax/naming of powershell commands: We haven’t addressed these yet but we will be reviewing the commands before the next preview.

 

The posts that we got most of your feedback from were:

 

Please keep the feedback coming!

Rowan Miller
Program Manager
ADO.NET Entity Framework

Comments

  • Anonymous
    August 05, 2011
    Awesome... Glad to know that the team is working on this stuff...

  • Anonymous
    August 05, 2011
    What about fixing the bug that prevents profilers from working with EF? See: ayende.com/.../entity-framework-4-1-update-1-backward-compatibility-and-microsoft

  • Anonymous
    August 05, 2011
    Well we did a code first with base classes and interface but things went completely bezerk in de db. A really messy db structure with weird realtions was the result.  If you going to do code first please keep it simple (no base classes for example)

  • Anonymous
    August 05, 2011
    Hmm... not so sure about 'deployment code' instead of 'deployment script (SQL)'... but I'll take it as it comes. Big YES to more info on the deployment story. Please take it all the way!!!

  • Anonymous
    August 05, 2011
    Can't ask for much more than listening to feedback. Spot on!

  • Anonymous
    August 05, 2011
    @Brian Vallelunga - We are working on the logistics of the fix for that issue at the moment, we'll post up our plans shortly. @Edward - Code First will use TPH mapping for inheritance by default and you have the same options for changing the database schema that are available when using the designer approach with EF. If you have particular examples I'd love to hear about them (rowmil 'AT' microsoft 'DOT' com) @Sumit - Migrations includes a -script option, so even with the scripts moving to code you can always get a SQL script that can be tweaked and passed to a DBA to apply to a production database etc.

  • Anonymous
    August 05, 2011
    Love how you're releasing early/often and truly listening to feedback. I personally liked the automatic/magic migrations; as you develop a more manual approach, it'd be nice to keep the magic as an option.

  • Anonymous
    August 05, 2011
    @Saqib - Absolutely! The automatic functionality will still be there. The biggest change is that custom scripts will be defined in code rather than SQL.

  • Anonymous
    August 05, 2011
    Great! Love Rob's "dream" mockup, that's basically what we're looking for.  Ideally the auto-magical change detection can just be a "generate migration file from changes" command that then detects if there are any schema changes and generates the code-based migration file you would otherwise have hand-coded in C#/VB.NET/whatever (possibly also with another command to generate a pure SQL migration for those who need to hand it off to a DBA, but we'd love the generated migrations to be pure C# so they are more declarative and match our hand-rolled migrations). Also the convention of using a timestamp as the file name and version number tends to work better than using incrementing version numbers IMHO, since it solves the issue of merge conflicts.  So for example 201108051806.migration instead of 2.migration.  If we can save having to explicitly add a version attribute to each migration by using a nice file or class naming convention then all the better.  If a human-readable name is also desired you could do something where each file could optionally be named something like 201108051806SomeExtendedName.migration and the class named Migration201108051806SomeExtendedName, with the timestamp location being standardized in the class/file name and everything after it ignored.  Then the timestamped version number could be parsed out of the class name rather than explicitly set via an attribute (like how some frameworks do it).  Anything to minimize friction. Thank you for listening to the community!

  • Anonymous
    August 06, 2011
    @Rowan - You need to hurry up on that fix, we need that profiler working.

  • Anonymous
    August 23, 2011
    The comment has been removed

  • Anonymous
    September 02, 2011
    First, good work! We really like where Entity Framework is going.  In regards to "migration", it makes sense (especially for simple applications or applications developed in small controlled environments) to make it simple for a developer to publish application changes (including Model changes with or without data manipulation) to a production server and have it just work.  If we add a column, re-scaffold or modify views, and publish, why should we (in our simple environment) have to switch over to writing Transact-SQL scripts?   With that said, we are "live" and running our application in a production environment and everything works perfectly.  Now we have made a simple model change, adding a property, and need to add the field to the database; which led us to all of these conversations.  So the "migration" solution is perfect for our needs.   However, we need to update the schema on our hosted environment's SQL Server now. Before going "live" it was a snap.  Simply use publish using Web Deploy in Visual Studio after ensuring the checkbox "Include all databases configured in Package/Publish SQL tab" is checked.  Of course we have the finer details included to "DropCreateDatabaseIfModelChanges" and override the "Seed" to put some data into the database.  Any test data, of course, is toast--but no big deal.   Now it is a big deal.  So, we patiently wait for "migration".  In the meantime, we just want to make sure we are going to accomplish this latest update to the application (the adding of a property and hence a field) the correct way.  We believe we should:

  1. In the Package/Publish Web, leave the "Include all databases configured in Package/Publish SQL tab" checked.
  2. In the Package/Publish SQL tab, select "Schema Only" for "Database scripting options".
  3. Include a custom SQL script to "ALTER" the table adding the field.
  4. Uncheck the "[Auto-generated Schema Only]" script. Or, remote into the SQL Server and add the field manually, or run the script on the server. Fantastic work once again.
  • Anonymous
    September 02, 2011
    First, good work! We really like where Entity Framework is going.  In regards to "migration", it makes sense (especially for simple applications or applications developed in small controlled environments) to make it simple for a developer to publish application changes (including Model changes with or without data manipulation) to a production server and have it just work.  If we add a column, re-scaffold or modify views, and publish, why should we (in our simple environment) have to switch over to writing Transact-SQL scripts?   With that said, we are "live" and running our application in a production environment and everything works perfectly.  Now we have made a simple model change, adding a property, and need to add the field to the database; which led us to all of these conversations.  So the "migration" solution is perfect for our needs.   However, we need to update the schema on our hosted environment's SQL Server now. Before going "live" it was a snap.  Simply use publish using Web Deploy in Visual Studio after ensuring the checkbox "Include all databases configured in Package/Publish SQL tab" is checked.  Of course we have the finer details included to "DropCreateDatabaseIfModelChanges" and override the "Seed" to put some data into the database.  Any test data, of course, is toast--but no big deal.   Now it is a big deal.  So, we patiently wait for "migration".  In the meantime, we just want to make sure we are going to accomplish this latest update to the application (the adding of a property and hence a field) the correct way.  We believe we should:
  1. In the Package/Publish Web, leave the "Include all databases configured in Package/Publish SQL tab" checked.
  2. In the Package/Publish SQL tab, select "Schema Only" for "Database scripting options".
  3. Include a custom SQL script to "ALTER" the table adding the field.
  4. Uncheck the "[Auto-generated Schema Only]" script. Or, remote into the SQL Server and add the field manually, or run the script on the server. Fantastic work once again.

  • Anonymous
    September 04, 2011
    Step 4) Uncheck the "[Auto-generated Schema Only]" script unchecks the "Pull data and/or schema from an existing database" checkbox. So, this solution does not work. We tried also editing the "...SchemaOnly.sql" file to only include the ALTER to add the field, but it recreates the file.  So it looks like the only option is to remote into the SQL Server and add the field manually or run the script on the server.  At least until the Migration functionality is developed.

  • Anonymous
    November 01, 2011
    @Rowan Miller: "We are working on the logistics of the fix for that issue at the moment, we'll post up our plans shortly." Define "shortly". Three months later, and there's still no sign of any plans to fix this. It doesn't just affect generic providers: try using an OleDbConnection, and EF4.1+ will use the "System.Data.Odbc" provider! >:(

  • Anonymous
    November 01, 2011
    The comment has been removed