6

I am thinking of using Entity Framework 6 Code First for database interaction alongside DbUp for database schema update. The thing is I don't want to use EF migration for reasons. So, the workflow that I've reached to is:

  1. Change model (add POCOs, alter properties, etc)
  2. Run Add-Migration temp_file in Visual Studio Package Manager Console
  3. Run Update-Database -Script in Visual Studio Package Manager Console
  4. Grab the generated sql scripts including insertion of new row in table __MigrationHistory
  5. Create a new .sql file and past the generated scripts
  6. Delete temp_file
  7. Run DbUp

It works perfectly locally and on production server, however I don't feel comfortable with adding and then deleting temp_file every time a new migration is generated (I wish there were a way to permanently stop temp_file being added to the solution.).

So question: Is there a better way to do database migration with DbUp using Entity Framework?

Hans
  • 2,674
  • 4
  • 25
  • 48
  • I'm confused, so you don't use the migration after its been generated and just delete the class? – TheGeneral Jan 28 '18 at 03:45
  • @Saruman Yup, correct. – Hans Jan 28 '18 at 05:10
  • I think you can extend the package manager console with power shell profiles and you might be able to write a custom command to suit your needs – TheGeneral Jan 28 '18 at 05:24
  • @Saruman True, but I am doubtful about my approach. EF and DbUp have been around for a good while and the proposed command should have been already created. – Hans Jan 28 '18 at 06:08
  • what if you use a tool to generate create tables script from your POCO models and simply do not rely on Entity Framework for migration, then every time u run dbup the models will be created. – Behzad Jan 30 '18 at 07:53
  • @Behzad Sounds interesting. Do you know any? – Hans Jan 31 '18 at 01:11
  • ef does it, https://learn.microsoft.com/en-us/ef/core/miscellaneous/cli/dotnet, however i think ivans answer is a better approach – Behzad Feb 03 '18 at 11:46

2 Answers2

4

In most of the cases you can skip steps (2) and (6) by utilizing the Automatic Code First Migrations:

Automatic Migrations allows you to use Code First Migrations without having a code file in your project for each change you make.

By default automatic migrations are disabled. You enable them by adding the following like in your db migration configuration class constructor (usually called Configuration and located under Migrations sub folder):

AutomaticMigrationsEnabled = true;

Some things to consider:

  • Documentation states that automatic migrations have limitations, so be aware.
  • You can mix automatic and code based migrations (in other words, the proposed and your current approaches).
  • The benefits of your current approach is that you can preview how EF interprets your model changes and also add/remove/change parts of the migration code.
  • The automatic migrations have been deprecated (don't exist) in EF Core, so in EF Core projects you have to use something similar to your current approach, except that you have to keep the generated migration code files.
Ivan Stoev
  • 195,425
  • 15
  • 312
  • 343
  • `Automatic Migration` is not an option for large enterprise productions. Sometimes, what can be achieved with some simple `SQL` scripts within few minutes is done by `EF` in hours – Hans Jan 31 '18 at 01:14
  • @Hans I don't understand your comment. If you read carefully my answer, I'm not suggesting automatic migrations for actually upgrading the database, but for generating the sql script without issuing `Add-Migration` and `temp_file` . Exactly what you wanted. Skip steps 2 and 6. Do steps 1, 3, 4, 5, 7. – Ivan Stoev Jan 31 '18 at 02:03
  • I don't understand how to get `SQL` scripts back though `Automatic Migration`. Can you elaborate please? – Hans Jan 31 '18 at 02:12
  • 1
    Just do what you are doing currently **except** `Add-Migration` command. After making modifications to the model, execute `Update-Database -Script` in Visual Studio Package Manager Console. The command will generate `sql` file and will open it in VS. Grab the generated `sql` scripts... etc. etc. – Ivan Stoev Jan 31 '18 at 02:19
  • It worked! Thanks! You answered my question although I'm waiting for other possible solutions. And I need to dig into limitations. The final bit if you don't mind: What strategy do you follow in your projects? – Hans Jan 31 '18 at 02:42
  • I use both, but it doesn't really matter because recently I'm playing almost exclusively with what they call *the future of EF* - EF Core, and it does not offer such choices (at least for now). – Ivan Stoev Jan 31 '18 at 03:00
  • This is exactly what I do. I'm thinking about using SQL Data Tools to store database scripts in version control. We are having some issues with three environments and many developers, so I'm studying it to see if it can help us with this problem. – Alisson Reinaldo Silva Feb 05 '18 at 15:56
2

Maybe this answer is too late, but maybe it will be useful as well. I completely understand your approach to use Entity Framework as ORM and a different tool for schema migration. But choosing DbUp requires you to write manually SQL or generate them as you described above. I suggest considering to use FluentMigrator instead of DbUp. It follows the same philosophy, but allows writing migration steps in C# using fluent syntax. In addition, it supports downgrades, i.e. rollback.

Here is an example:

[Migration(1)]
public class CreateUserTable : Migration
{
    public override void Up()
    {
        Create.Table("Users");
    }

    public override void Down()
    {
        Delete.Table("Users");
    }
}
Boris Modylevsky
  • 3,029
  • 1
  • 26
  • 42
  • Thanks Boris. I haven't dig into `DbUp` very much but I've heard many successful stories that something was doable in `DbUp` while not possible using other tools. Specially, I think the philosophy of `DbUp` which always is `Up` better than other approaches. – Hans Feb 07 '18 at 04:34
  • 1
    You can follow the same technique with FluentMigrator by not implementing Down method. You may leave it empty. – Boris Modylevsky Feb 07 '18 at 05:31
  • 1
    Yes makes sense. – Hans Feb 07 '18 at 08:26