2

Closed

Migrations: Support custom derived MigrationOperation

description

There is a forum post with the following questions. Does anyone know the answers?

http://social.msdn.microsoft.com/Forums/en-US/adodotnetentityframework/thread/cba32c2a-fe84-4d6b-93ff-077dc3046589

· There are some extensibility points in EF Code First migrations.

In Migrations.Configuration I can set the SqlGenerator:

SetSqlGenerator(""System.Data.SqlClient"", new CustomizedSqlGenerator());

I can derive from SqlServerMigrationSqlGenerator and override methods.

I can make new operations derived from MigrationOperation - but the DbMigration base class doesn't allow you to add them to it's internal list (AddOperation is internal)

A class derived from SqlServerMigrationSqlGenerator will not recognize additional operations (the Generate(IEnumerable<MigrationOperation>) reflects against it's own Generate methods, not derived ones, apparently). I could create a completely custom MigrationSqlGenerator, but I still couldn't get the operations from the migration.

I can just write Sql strings in the DbMigration, but it would be nicer to use more structured and potentially database agnostic MigrationOperations.
  1. Could the DbMigration.AddOperation be made public (with the caveat that it won't do anything without the supporting MigrationSqlGenerator).
  2. Could the SqlServerMigrationSqlGenerator.Generate(IEnumerable<MigrationOperation>) method be revised to look for any supporting Generate(MigrationOperation) - or some other extensibility point where I can plug in new MigrationOperations?
This item was migrated from the Migrations work item tracking system [ID=47500].
Closed Mar 7, 2013 at 8:18 PM by lukew
Verified

comments

iceclow wrote Feb 3, 2013 at 11:05 PM

Hi,

Annouce that as we commented here I have submitted the pull request that enables this scenario.

Any comments are welcome.

lukew wrote Feb 18, 2013 at 6:49 PM

Updated pull request link here

BriceLambson wrote Feb 19, 2013 at 4:56 PM

Fixed in changeset 020bcea047a0

RoMiller wrote Mar 1, 2013 at 8:29 PM

Moving from Future into EF6 because this was contributed for the EF6 release.