タグ: ef-core

一度だけ実行した 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 は、値の種類が少なく、データの偏りが大きくて値ごとに別のプランが必要な場合だけに使います。

EF Core 11 RC 1 では、ToJson() メンバーに対する HasIndex(...).IsUnique() は一意性を強制しません。SQL Server は IsUnique を無視し、SQLite はドキュメント全体にインデックスを張ります。JSON の値を計算列として公開し、その列に一意インデックスを設定してください。

エンティティを読み込み、List.Add を呼んで保存すると、jsonb ドキュメント全体が書き換えられ、同時に行われた追加は黙って失われます。追加処理は jsonb の || 演算子を使った 1 つの UPDATE にまとめます。ExecuteSqlAsync を使うか、ExecuteUpdateAsync の中でマップした関数を使い、さらに @> によるガードで冪等にします。

Oracle.EntityFrameworkCore 10 の UseSequence で EF Core のキーを Oracle のシーケンスにマッピングします。プロバイダーが実際に出力する DDL と INSERT の SQL、既存のシーケンスやレガシーなトリガーを使う方法、引用符と HiLo でつまずきやすい理由、そして ORA-00001 を起こさずに ID 列をシーケンスへ移行する方法を解説します。

Gas という名前のテーブルは Ga というエンティティにスキャフォールドされます。組み込みの Humanizer 複数形化サービスを独自の IPluralizer に置き換え、スタートアッププロジェクトの IDesignTimeServices から登録する方法と、そこで TryAddSingleton が黙って何もしない理由を解説します。

ハンドラーの存在チェックは、あなたが思っているようなガードではありません。inbox テーブルに一意インデックスを張り、業務上の変更と同じ SaveChanges でマーカーを書き込み、勝者はデータベースに決めさせます。さらに、それを静かに台無しにする ExecuteUpdate の罠も扱います。

EF Core 11 が生成する PK_、FK_、AK_、IX_ の名前を 1 つの IModelFinalizingConvention ですべて付け替え、明示的に指定した名前を優先させ、識別子の長さ制限に収め、既存データベースで次のマイグレーションが生成するクラスター化インデックスの再構築を回避します。

EF Core 11 では UseSqlServer の既定の互換性レベルが 160 になり、LEAST、GREATEST、2 引数の LTRIM/RTRIM が SQL に入るようになりました。すべての Take(n).FirstOrDefault() も対象です。SQL Server 2022 以降なら 160 のままにし、SQL Server 2019 がまだ動いている環境が一つでもあれば UseCompatibilityLevel(150) で固定してください。

EF Core の SQL Server 存在チェックは、EnableRetryOnFailure の有無にかかわらずエラー 18456 を丸 1 分間リトライします。即座に失敗させるか、RetryTimeout を短くするか、EF Core 12 を待ってください。