タグ: ef-core

決め手はスタートアッププロジェクトにある 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 つの方法を紹介します。

Pomelo 9.0.0 は EF Core Relational 9.0.x しか許可しておらず、EF Core 10 向けのビルドもありません。EF Core のパッケージをすべて 9.0.x にそろえるか、Microting.EntityFrameworkCore.MySql 10.0.x に切り替えてください。警告を抑制すると起動時にクラッシュします。

ツールパッケージがインストールを実行している SDK よりも新しい .NET を対象としているか、そもそも .NET ツールではありません。新しい SDK を使うか、互換性のある tools フォルダーを持つツールのバージョンを固定するか、--framework を強制してください。

DbSet.Local.FindEntry(key) を使えば、データベースへの往復やスキャンなしで、指定したキーのエンティティが追跡されているかを変更トラッカーに問い合わせられます。この確認で Entry(entity).State が当てにならない理由、Find がクエリを発行する理由、EF Core 10 で検証済みの AttachOrMerge ヘルパーを紹介します。

コンパイル済みモデルとは、OnModelCreating を実行せずに EF Core のモデルを再構築する生成済み C# コードです。EF Core 11 RC1 での実測では、500 エンティティでモデルの読み込みが 714 ms から 215 ms に短縮されます。ただし EFOptimizeContext の後継である MSBuild 経由の方法は遅く、古くなったモデルはエラーなしで使われ続け、クエリフィルターがあると生成そのものができません。

shadow プロパティは、対応する CLR プロパティがないまま EF Core が追跡する列です。EF Core 11 がそれを作る理由 (FK プロパティの欠落、FK の命名ミス、型の不一致、リレーションシップの二重構成)、マイグレーションで BlogId1 のような列を見つける方法、原因ごとの修正方法、そして意図的に shadow プロパティを使う方法を解説します。

AddDbContextPool は DI スコープごとに 1 つのスコープ付き DbContext を渡すため、2 つのクエリを同時に実行できません。AddDbContextFactory と AddPooledDbContextFactory は呼び出しごとにコンテキストを返すので、並列クエリに向いています。EF Core 11 RC 1 での計測では、プール付きファクトリはコンテキストを 342 ns、40 B で作成しますが、プールなしでは 17 us、44 KB かかります。

Migrations フォルダーを削除して新しい InitialCreate を生成すると、EF Core はテーブルが既に存在することを知りません。開発用データベースを削除するか、新しいマイグレーションを実行せずに __EFMigrationsHistory に記録します。

一度だけ実行した SET は、Npgsql が接続をプールに戻した瞬間に DISCARD ALL で消去されます。Search Path と Options の接続文字列キーワードで search_path と statement_timeout をスタートアップパケットに含め、うまくいかない場合は ALTER ROLE か ConnectionOpened インターセプターにフォールバックします。また、UsePhysicalConnectionInitializer の SET が黙って失われる理由も解説します。

EF.Constant はキャプチャした値を SQL リテラルとして埋め込み、EF.Parameter はリテラルを SQL パラメーターに変換します。基本は EF Core の既定のままにし、動的に組み立てた式ツリーが呼び出しのたびに再コンパイルされるのを防ぐには EF.Parameter を使います。EF.Constant は、値の種類が少なく、データの偏りが大きくて値ごとに別のプランが必要な場合だけに使います。