EntityFramework Core のエンティティを名前変更したら、テーブル削除/新しい名前でテーブル新規作成のマイグレーションコードが生成されてしまった

C# による、リレーショナルデータベースにアクセスするプログラムを実装していての話。

SQL Server などのリレーショナルデータベースにアクセスする C# プログラムを作成する際、採用しているデータベースアクセスライブラリは、もうここ数年は EntityFramework Core (以下 EFCore) ばかりである。

さてそんな、EFCore を使っての、データベース構造を変更していく作業を進めていた中で、それは起きた。

開発途中、エンティティ名変更の要件が発生

まずとあるプログラムの開発着手当初、下記のようなエンティティを作成していた。

まずエンティティ型として以下のような "Person" クラスを用意し、

public class Person {

  public int Id { get; set; }

  public string Name { get; set; }

}

そしてこの "Person" クラスをエンティティ型としたデータセットプロパティを、データベースコンテキストクラスに追加しておく。

public class MyDbContext : DbContext {

  public DbSet<Person> People { get; set; }

  ...

しばしこの構造で開発を進めていたが、その後、このエンティティ型 "Person" を "BusinessPerson" に名前変更するのが良かろう、ということになった。

そこでまずクラス名を "Person" から "BusinessPerson" 変更し、

public class BusinessPerson {

  ...

データセットプロパティ名も "People" から "BusinessPeople" に変更。

public class MyDbContext : DbContext {

  public DbSet<BusinessPerson> People { get; set; }

  ...

あとは、以上のコードの変更にデータベース構造を追随させるマイグレーションコードを生成すれば OK だ。

生成されたマイグレーションコードが期待と違う!

ということで、(Visual Studio 上で作業していたので、"dotent ef" コマンドの実行ではなく) Visual Studio のパッケージマネージャコンソールウィンドウ内にて、マイグレーションコード生成のコマンド "Add-Migration ..." を実行した。

PM> Add-Migration RenamePersonToBusinessPerson

よしこれで完了、と思ったのだが、生成されたマイグレーションコードを見ると、なんと、既存テーブル ("People") を削除 ("DROP TABLE") してしまい、それから変更後の名前のテーブル ("BusinessPeople") を新規作成 ("CREATE TABLE") するコードになっていたのだ (以下、生成されたマイグレーションコードの抜粋)。

...

migrationBuilder.DropTable(

    name: "People");

migrationBuilder.CreateTable(

    name: "BusinessPeople",

...

これでは、既に People テーブルに格納されていたレコードが全滅である。

期待していたのは、あくまでもテーブル名の変更を行なうマイグレーションコードの生成である。

これはどうしたことか。

EFCore は悪くない

冷静になって考えてみると、こんなマイグレーションコードが生成されるのも無理からぬ事がわかってきた。

EFCore がエンティティ周りのコードの変更を追跡するにあたり、名前の変更であると認識するには、変更の前後での、当該エンティティの "つながり" がわかっていることが必要だ。

実際に EFCore のソースコードを確認したわけではないが、今回の振る舞いから推測するに、EFCore がコード変更の前後での "つながり" を認識するヒント要素は、以下の2つがあるのではないかと思われた。

• エンティティ型のクラス名
• データセットプロパティ名

つまり、コード変更の前後で、上記いずれか片方でも一致するデータセットプロパティは "つながり" がある、と認識されるのではないか、ということだ。

それが今回は、上記2項目をいずれも変更してしまい、コード変更の前後でつながりがないように見えてしまうことになったので、それで EFCore は、"名前の変更" ではなく "削除""新規作成" と認識してしまっただと考えられた。

ということで、以上の推測に基づき、マイグレーションコードの生成を二段階に分けて実行することでやり直してみた。

1. まず、エンティティ型のクラス名 "Person" を "BusinessPerson" に変更
2. ここで一旦、"Add-Migration ..." 実行
3. 次に、データセットプロパティ名 "People" を "BusinessPeople" に変更
4. 最後にもう一度、"Add-Migration ..." 実行

こうすればマイグレーションコードの生成を実行するタイミングでは、"つながり" を認識するためのヒント要素のいずれか片方は一致し続けるので、今度は大丈夫なはずだ。

結果は予想どおり、テーブル名変更のデータベースマイグレーションコードが生成された。(以下抜粋)

...

migrationBuilder.RenameTable(

    name: "People",

    newName: "BusinessPeople");

...

なお、上記の手順は、先にエンティティのクラス名を変更して、次にデータセットプロパティ名の変更という順序としたが、この順序は逆にしても、各マイグレーションコード生成時に "つながり" を認識するためのヒント要素のいずれか片方は一致しているのは変わらない。

つまり、データセットプロパティ名を変更してから、エンティティのクラス名を変更しても、テーブル名変更として認識されるはずだ。

ということで、念のため、上記逆順でも試してみたが、これまた予想どおり、ちゃんとテーブル名変更のデータベースマイグレーションコードが生成された。

まとめ

ということでちょっと手間取ってはしまったが、EFCore の気持ちになって考えてみることで、どうにか解決に至ることができた。

最初は「えっ、なんでテーブル名の変更にならないの!?」とか思ってしまったが、

「プログラムは思ったとおりに動くわけではない。作られたとおりに動くだけだ。」

みたいなどこかで聞いたような格言 (?) のような顛末となった。