IdentityServer4の日本語マニュアル

いつの間に！！素晴らしい
https://identityserver4-ja.readthedocs.io/ja/latest/

entity framework で入れ子のマイグレーションのロールバックを考える→入れ子にならないようにPR時に考慮する？

entity framework で、平行開発の都合上マイグレーションスクリプトが入れ子になってしまった場合に、マイグレーションのダウングレードを行えるのかを検証しました。

今の時点の結論としては、入れ子になっているとアップグレードは問題ないけれど、ダウングレードがうまくできないのでfeatureブランチからプルリクを上げる前にマイグレーションが進んでいる場合は自分のブランチに取り込んだ上でマイグレーションスクリプトを作り直すのが良い気がします。
ちょっと自信がないんですが、これ以外に対応する方法が思つかないです。

入れ子になっていないダウングレード

こんな状態のデータベースがあったとします。

マイグレーションスクリプトはこんな感じになっているとします。

この状態で、Jobテーブルの追加の前に戻したいとしたら、こんな感じのコマンド打てばいいですよね。

dotnet ef database update 20190911020136_AddCompany

入れ子のダウングレード

じゃぁ、もし別ブランチでマイグレーションスクリプトを追加する作業が並行で走っていた場合は？たとえば、こんなブランチがmasterにマージされた場合は？

この時点で、DbContextとDbContextModelSnapshotにコンフリクトが起きるので、この時点で怪しい空気ですね。今回は似たような属性情報を持ったテーブルを追加したのでコンフリクトが起きたけれど、場合によってオートマージで乗り切られる可能性もありますね。

この時点でソリューションエクスプローラーのマイグレーションスクリプトと__EFMigrationsHistoryの差はこんな感じになっています。
20190911015814_AddAddressと20190911021045_ModifyAddressAddAddress2が未適用ですね。見事に入れ子になっていますね。

この状態でデータベースのアップグレードをすると、、、普通に入りますよね。

じゃぁ、ここの状態で、あっ、戻したいってなったらどうするんでしょう、Entity Frameworkのデータベースダウングレードの場合、戻すべき場所を指定するのでどこに戻していいかわからない、、、
試しに時系列的に最後に上がったはずの20190911021045_ModifyAddressAddAddress2を指定してダウングレードしてみると？

dotnet ef database update 20190911021045_ModifyAddressAddAddress2

当たり前なんですが、消えちゃいけない子(20190911023044_AddJobと20190911023127_ModifyJobAddNameProperty）まで消えちゃいましたね。

ダウングレード時に実施したくないマイグレーションを一時的に__EFMigrationsHistoryから削除してみたら？

ダウングレードしたいマイグレーションは20190911015814_AddAddressと20190911021045_ModifyAddressAddAddress2だけなので、__EFMigrationsHistoryから一時的に
ダウングレードを実施したくないマイグレーションを消してみる。

DELETE FROM `db`.`__EFMigrationsHistory` WHERE (`MigrationId` = '20190911020136_AddCompany');
DELETE FROM `db`.`__EFMigrationsHistory` WHERE (`MigrationId` = '20190911023044_AddJob');
DELETE FROM `db`.`__EFMigrationsHistory` WHERE (`MigrationId` = '20190911023127_ModifyJobAddNameProperty');

この場合、20190911015404_AddUserにまで戻すしかないのでこうすると、、、

dotnet ef database update 20190911015404_AddUser

Addressテーブルに関するマイグレーションだけ消えてくれましたね。

さっき削除したマイグレーションを戻せば、一応アップグレード前と同じ状態は作れました。

INSERT INTO `db`.`__EFMigrationsHistory` (`MigrationId`, `ProductVersion`) VALUES ('20190911020136_AddCompany', '2.2.4-servicing-10062');
INSERT INTO `db`.`__EFMigrationsHistory` (`MigrationId`, `ProductVersion`) VALUES ('20190911023044_AddJob', '2.2.4-servicing-10062');
INSERT INTO `db`.`__EFMigrationsHistory` (`MigrationId`, `ProductVersion`) VALUES ('20190911023127_ModifyJobAddNameProperty', '2.2.4-servicing-10062');

ダウングレードを考慮する場合は入れ子のトランザクションを作らない

どうしようもなくなったら上記の作業で戻すしかないのかもしれませんが、てんぱっている中これをやるのはつらそう、、、ということで、基本的には入れ子にならないようにプルリクエストのレビュー時にはじくみたいな運用になっちゃうのかなぁ、、、