New Entity Framework Feature Request: Migrations: Allow Multiple Migration SQL Generator per Provider

I’ve just added this feature request to Entity Framework Uservoice site and was wondering whether you’d like to up-vote / share / tweet it if you think it’s good to have.

Migrations: Allow Multiple Migration SQL Generator per Provider

http://data.uservoice.com/forums/72025-entity-framework-feature-suggestions/suggestions/3812292-migrations-allow-multiple-migration-sql-generator

Inline, here’s what the feature request is about:

One way to allow community to contribute to EF Migrations is allow us to create more `MigrationOperation`s.

For example, people can then add things like full text index, etc., things that are not in the core EF Migrations and are just boring SQL statements that need to be combined together.

Currently, to build a provider agnostic `MigrationOperation`, you need to write the SQL generated for the operation in a class derived from `MigrationSqlGenerator`. If you want to add `CreateFullTextCatalog` operation and support SQL Server for example, you inherit `SqlServerMigrationSqlGenerator`, add a `Generate` method for your operation, and ensure all other operations generators are still called from the base class.

Not just that thius is ugly, but now the `MigrationConfiguration` has to use your generator for `SqlClient` provider, the `SetGenerator` and `GetGenerator` methods in ‘MigrationConfiguration` only deal with one generator per DB-type provider.

So, if someone else wrote their own `MigrationOperation` and `SqlServerMigrationSqlGenerator` for it, I cannot use both in the same `MigrationConfiguration`.

This makes creating generic `MigrationOperation` quite a bad idea, maybe people will just forget about Db-agnostic code and build their operations deriving from `SqlOperation` and generating a provider-specific statement from their operation, but this means the entire `MigrationSqlGenerator` is unusable, right?

The simplest answer for this seems to be supporting multiple `MigrationSqlGenerator` for the same provider in `MigrationConfiguration`, or else maybe provide a different way to make building provider-agnostic operations possible.

 

Thanks.

 

Related Information

If you are interested in how I got to learn about how this works, well, there is of course trying to create my own `MigrationOperation`, and reading source code via Resharper downloading symbols and doing decompiling for me. However, this article is also a good source to learn about writing EF6 Migrations Operation:

EF6: Writing Your Own Code First Migration Operations

 

Enjoy.

Share With Friends:

How did I learn that?

As a bonus for coming here, I'm giving away a free newsletter for web developers that you can sign up for from here.

It's not an anything-and-everything link list. It's thoughtfully collected picks of articles and tools, that focus on Angular 2+, ASP.NET (4.x/MVC5 and Core), and other fullstack developer goodies.

Take it for a test ride, and you may unsubscribe any time.

You might also want to support me by checking these out [Thanks]: