EF Core で自己参照の多対多リレーションシップ (フォロワー/フォロー中) を構成する方法
EF Core 11 で単一の User エンティティにフォロワーとフォロー中をモデル化します。規約が何を生成するか、SQL Server が結合テーブルの外部キーの片方を黙って ClientCascade に変える理由、タイムスタンプ付きの明示的な Follow 結合エンティティのマッピング方法、そしてエラー 547 や 1785 を出さずにユーザーを削除する方法を解説します。
タグ: ef-core-11
57 件 · ページ1/6
EF Core が SQL Server の `date` 列を `DateOnly` と `DateTime` のどちらでスキャフォールドするかは何で決まるのか
決め手はスタートアッププロジェクトにある SQL Server プロバイダーの EF Core バージョンです。EF Core 7 以前は date を DateTime に、EF Core 8 から 11 までは DateOnly にスキャフォールドします。この判断を行う型マッピング、EF Core 7、8、10、11 RC 2 での実測出力、そして列を黙って datetime2 に再マッピングすることなく DateTime に戻す 2 つの方法を紹介します。
EF Core 11 のコンパイル済みモデルとは何か、有効にする価値があるのはどんなときか
コンパイル済みモデルとは、OnModelCreating を実行せずに EF Core のモデルを再構築する生成済み C# コードです。EF Core 11 RC1 での実測では、500 エンティティでモデルの読み込みが 714 ms から 215 ms に短縮されます。ただし EFOptimizeContext の後継である MSBuild 経由の方法は遅く、古くなったモデルはエラーなしで使われ続け、クエリフィルターがあると生成そのものができません。
EF Core 11 の shadow プロパティとは何か、なぜマイグレーションに現れたのか
shadow プロパティは、対応する CLR プロパティがないまま EF Core が追跡する列です。EF Core 11 がそれを作る理由 (FK プロパティの欠落、FK の命名ミス、型の不一致、リレーションシップの二重構成)、マイグレーションで BlogId1 のような列を見つける方法、原因ごとの修正方法、そして意図的に shadow プロパティを使う方法を解説します。
修正: EF Core でスカラー結果に SqlQueryRaw<T> を使うと発生する Invalid column name 'Value'
EF Core は、First、Where、Max、Single を追加した時点で、スカラーの SqlQuery<T> をサブクエリでラップし、Value という名前の列を選択します。SQL の列に AS Value のエイリアスを付けるか、先にマテリアライズしてください。
解決: EF Core のマイグレーションをリセットした後の There is already an object named 'X' in the database
Migrations フォルダーを削除して新しい InitialCreate を生成すると、EF Core はテーブルが既に存在することを知りません。開発用データベースを削除するか、新しいマイグレーションを実行せずに __EFMigrationsHistory に記録します。
EF Core 11 で JSON にマッピングされたプロパティに一意インデックスを追加する方法 (SQL Server と SQLite)
EF Core 11 RC 1 では、ToJson() メンバーに対する HasIndex(...).IsUnique() は一意性を強制しません。SQL Server は IsUnique を無視し、SQLite はドキュメント全体にインデックスを張ります。JSON の値を計算列として公開し、その列に一意インデックスを設定してください。
IPluralizer で dotnet ef dbcontext scaffold のテーブル名複数形化をカスタマイズする方法
Gas という名前のテーブルは Ga というエンティティにスキャフォールドされます。組み込みの Humanizer 複数形化サービスを独自の IPluralizer に置き換え、スタートアッププロジェクトの IDesignTimeServices から登録する方法と、そこで TryAddSingleton が黙って何もしない理由を解説します。
2 つのアプリインスタンスが同じメッセージを消費するときに EF Core 11 で冪等なメッセージ処理を保証する方法
ハンドラーの存在チェックは、あなたが思っているようなガードではありません。inbox テーブルに一意インデックスを張り、業務上の変更と同じ SaveChanges でマーカーを書き込み、勝者はデータベースに決めさせます。さらに、それを静かに台無しにする ExecuteUpdate の罠も扱います。
1 つの ASP.NET Core リクエストの中でデータベース書き込みと Azure Blob Storage へのアップロードの整合性を保つ方法
SQL Server と Blob Storage をまたぐトランザクションは存在しません。データベースが既に知っている名前にアップロードし、コミットは後から行い、失敗時には補償し、クラッシュの隙間はスイーパーに片付けさせます。条件付き作成を黙って上書きに変えてしまう UploadAsync のオーバーロードについても。