DisableRelationMappingCache
概要
アーキテクト向けの機能です。
基本概念
関連テーブルのEntityのインスタンスの(一回のDBアクセス内における)キャッシュを利用せずに、同じPK値だとしても別々のインスタンスを生成してパフォーマンスを落としてしまう機能です(@since 1.0.1)。 ちなみに、ここでいうキャッシュは一回のDBアクセス内における短い期間の一時的なキャッシュであり、他のスレッドや他のDBアクセスで共有されるキャッシュではありません。
setupSelect(Relation)を使って取得されるmany-to-oneの関連テーブル、例えば、会員に対する会員ステータスは、 複数の会員Entityから同じステータスの会員ステータスEntityを参照します。 そのとき、同じステータスであれば、会員ステータスEntityのインスタンスは全て同じインスタンスとなります。 これは、DBFluteのマッピング処理にて関連テーブルのEntityがキャッシュされているからです。
このキャッシュを利用せずに、同じ会員ステータスであってもインスタンスをそれぞれ別にさせることができる、というのか DisableRelationMappingCache です。 他の機能と相性が悪い可能性があります。例えば、LoadReferrerで親テーブルの子テーブル(会員ステータスの会員ログイン)を取得しようとしたとき、 同じ会員ステータスでもインスタンスが違うことが原因で、全ての会員ステータスEntityに会員ログインが紐付くとは限りません。
万が一でも、使いたくない機能ですが、万が一キャッシュをすることがアプリにとって都合が悪い、もしくは、キャッシュがあることで DBFlute 内部のマッピングのロジックに不都合がある場合に、取り急ぎの回避的な用途で利用できます。
ディベロッパー向けに思えますが、アーキテクトへの相談無しに利用してはいけません。そういう意味で、"アーキテクト向けの機能" と謳っています。
諸刃の剣
TwoEdgedSword 認定のされた機能です。自分を斬りつけて最も痛い思いをする可能性のある機能です。 意味もなくこのメソッドを呼んではいけません。
この機能が必要になった問題は既に直った
この機能が必要になった問題は、この機能が反映された同じバージョンで既に直っています。 よって、この機能は本当に不要と言えるかもしれませんが、念のため残しました。
業務的many-to-oneで、基点テーブル側のFKカラムが複合PKの関連テーブルに対して足りてなくて(A, BというPKカラムがあって、基点テーブルがAに対するカラムしか持っていない)、 別の関連テーブルのカラム(Bに対応するカラム)と複合的に合わせて初めて参照することができるパターン。 fixedConditionに別の関連テーブルのカラムを使った結合条件を足して many-to-one とするわけですが、 localColumnNameのカラム(ここではAカラム)だけではキャッシュのキーにならないため、マッピングがずれる問題がありました。 言葉で説明しても「ピン」と来ないかもしれません。そのくらいレアなケースです。
この問題は、既に解決されました。キャッシュのキーハンドリングのロジックを変更したことで、 キャッシュを有効にしたままでも、このレアケースに対応できるようにしました。 当然、通常パターンを含むそれ以外のパターンに影響がないことを前提での修正です(テストケースもさらに増やしました)。
実装方法
実装の流れ
disableRelationMappingCache() を呼び出します。
メソッド仕様
基本仕様
- 引数の指定
- なし
非推奨メソッド
deprecated になっています。将来的に削除されるわけではありませんが、"安易に使ってくれるな" ということを示します。
