Efcore: Provide Migration "Hooks"

[glatzert]

The issue

When I create a ef-migration during development, that migration often will not be final and might need recreation, due to database creation errors (like incorrect cascade chains or whatever else).
When I now try to provide additional methods for Up() and Down() i will have to add them to the migration, everytime I recreate it.
That could be solved, if the partial class MyMigration would provide partial stub methods, which I might or might not implement like PreUp(), PreDown(), PostUp(), PostDown().
This would allow to add StoredProcedures, Triggers or Schemas, which are not directly generated by EF in that methods and not lose that code on recreating the migration.

Example

MyMigration_20160531132500.cs

``` c#
public partial class InitialDatabaseSetup : Migration
{
protected override void Up(MigrationBuilder migrationBuilder)
{
PreUp(migrationBuilder);

        // .. original Migration Code .. //

        PostUp(migrationBuilder);
    }

    protected override void Down(MigrationBuilder migrationBuilder)
    {
        PreDown(migrationBuilder);

        // .. original Migration Code .. //

        PostDown(migrationBuilder);
    }   

    protected partial void PreUp(MigrationBuilder migrationBuilder);
    protected partial void PreDown(MigrationBuilder migrationBuilder);
    protected partial void PostUp(MigrationBuilder migrationBuilder);
    protected partial void PostDown(MigrationBuilder migrationBuilder);
}

MyMigration.Programability.cs

``` c#
 public partial class InitialDatabaseSetup : Migration
    {
        protected partial void PreDown(MigrationBuilder migrationBuilder){
            // .. my own code to delete SPs .. //
        }
        protected partial void PostUp(MigrationBuilder migrationBuilder) {
            // .. my own code to create SPs .. //
        }
    }

[bricelam]

You might be able to add them yourself by overriding UpOperations and DownOperations properties.

[bricelam]

But I do like the idea of adding some hooks that are easier to use in an external partial. Perhaps like BeforeUp, AfterUp, etc. methods on Migration that you can override.

[glatzert]

Uh.. that UpOperations and DownOperations looks awfully complicated compared to the possibility of some Before and After hooks. I suppose the hooks would be an inexpensive change, which would allow usecases like the descripted. That'd really be a "nice to have", I think 👍 . I'd also volunteer myself for an PR :)

[bricelam]

Sorry, that was just a possible way to workaround the limitation. This issue would be a great opportunity for a community contribution.

[rowanmiller]

We discussed as a team and we're no 100% sure that this is the right approach to take. Typically, if you have things you want to do before/after, but not have them included alongside the scaffolded code, then you would scaffold an additional blank migration and put the operations in there.

The main concern is that we don't want to introduce APIs etc. when we're not sure that it's something that many folks will want. This is the first request we've seen for the feature, so at this stage we'd rather wait for more feedback that folks want it.

[glatzert]

I think I understand that, but personally I don't like the approach, since migrations will stack up and I am a friend of having one migration per release.
Following your approach I will have to rollback two migrations and rebuild the custom one to be able to keep one migration for one release - or do I miss something?

As an additional note: perhaps you could at least make BuildOperations protected - so I could extend the Migration myself without needing to reimplement that method. Then the manual work is little, when it comes to recreating the migrations.

Thanks for your time :)

[ajcvickers]

Just so it doesn't get lost, we also discussed that if we did do this it might be better to have virtual template methods in the base class that a partial class could then choose to override. This would mean we wouldn't have to scaffold all the partial methods in every migration.

[bricelam]

I am a friend of having one migration per release.

I've always liked the idea of keeping two sets of migrations--one for day-to-day development, and one for release-to-release migrations. Each set would need to be stored in their own assembly. Use the optionsBuilder.UseSqlServer().MigrationsAssembly() to specify which set to use.

[glatzert]

Having multiple migration assemblies really did not come into my mind .. I will look into that. Thank you!

[markbeij]

I think this feature could really help me. I like to scaffold extra classes. The idea is to have a history table in my database for each 'normal' table. @bricelam, @ajcvickers, do you agree this should be possible to accomplish when this feature will be implemented?

Found this example in EF6: StackOverflow

sidenote: Since there are still doubts, I don't think label up-for-grabs is correct.

[ericnewton76]

Um, I agree with @glatzert The autogenerated files wipe out any custom stuff, like ahem, defining a Stored Procedure to be added in Up and removed in Down as part of the migration.

There very much should be a partial method in the autogen files for PostUp/PostDown or call them AfterUp/AfterDown.

I can partially agree with the stance to "make another migration", only if theres a clear way to link the two migrations together somehow, probably from the manual one to the auto generated one.

The base Migration class should have a virtual property string[] DependantMigrations that can be overriden in the manual one to specify the previous one is a dependency. This sounds like alot more work than just making sure there's a PostUp/PreDown empty partial methods on the autogen class file _(which existed in EF 6.1.3 and seems to have been removed in 6.2.0, grrr, need to cross post this there)_.

This way I can create another class file, manually curated by developers, that will survive "Add-Migration -force" while developing and evolving the schema as you develop.

OR

Encourage a v00000 naming approach, where the database schema versions constantly increase more sequentially instead of using todays datetime ugly format + some nonsensicalname. Postfixing b c etc then helps imply the dependency even if its not a handled via code. And the codegen should output a standard implementation of IMigration.Id { get { ... } } that returns the current class name... which would be v000000 v000001 v000002a v000002b v000003 and so on.