CheckInvalidQuery
概要
1.1.x (Java8版) より変わっています
1.1.x (Java8版) より、デフォルトでCheckInvalidQueryが有効になっています。nullや空文字の条件値は例外です。 また、メソッド名も少し変わっています。
- cb.ignoreNullOrEmptyQuery()
- nullと空文字を無視する (例外にしない)
- cb.checkNullOrEmptyQuery()
- nullと空文字を例外にする (挙動をデフォルトに戻す)
基本概念
ConditionBeanの絞り込み条件にて、無効な条件値(nullなど)を設定した場合に例外にします。
通常、Query の絞り込み条件の設定では、無効な条件値は "設定されなかったのと同じ" という扱いになり、例外にはならず無視されます。(ConditionBean の基本仕様)
無効な条件値を例外として扱いたい場合に、この機能を使うことで実現できます。"その ConditionBean で利用する条件値で無効なものは業務的に存在しない(やってこない)" ということが大前提で、例えば "このテーブルは件数が膨大なので間違っても全件検索したくない" というような場合に有効です。(すぐにわかる原因とはいえ、例えば 1000 万件レコードのテーブルに無条件の検索をしてしまうと、処理がすぐに戻ってこないのでややこしいものです)
ただ、基本的には ConditionBean に設定する前にしっかり null チェック(無効値チェック)していれば全く問題ありませんし、本来そうするべきと考えられます。 チェックは早い段階であればあるほどデバッグがしやすく、 また、値の安全性が確保されるためチェック以降のロジックがシンプルに実装できるようになります。ましてや、ConditionBean 以外のロジックも存在するのであれば、ConditionBean だけをチェックしても仕方ありません。 そういうことから、この機能を外部からのデータのチェックロジックの代わりにするのは推奨されません。
既に無効な条件値であることが明示的にチェックされているのであれば、この機能を使う必要は基本的にありません。 敢えて使うとなれば、チェックロジックが間違っているときのための保険のためのチェック としての利用が想定されています。
こういったことから、対象テーブルの件数が膨大で、かつ、外部から来る条件値とその条件値のチェックロジック自体が不安に思えるような場合 において、"より堅く実装する" という意味合いでこの機能を利用すると良いでしょう。
Behavior自体にもチェックが
例えば selectEntity() や queryDelete() のような、そもそも "条件なし実行" が(デフォルトでは)許されていない Behavior メソッドを利用する場合は、このチェック機能を使う意義は薄れます。 その場合、別途条件が付与されていても検索対象となる件数が多いというような場合に有効です。
一律の設定
この機能を利用せず一律の設定で無効な値を例外にしたい場合は、DBFluteConfig を利用します。
実装方法
実装の流れ
絞り込み条件などを設定する前に、ConditionBean の checkInvalidQuery() を呼び出します。
e.g. ConditionBeanに絞り込み条件が設定されているかどうか (Eclipseでコード補完) @Java
MemberCB cb = new MemberCB();
cb.chIQ // .chIQ と打って enter
--
cb.checkInvalidQuery()
cb.query().setMemberId_Equal(null); // 例外になる
メソッド仕様
メソッドを呼び出した後の Query 呼び出しのみ設定が有効になります。
複数の条件値を登録する条件
例えば、FromTo, DateFromTo や LikeSearch の SplitBy などの "一つのカラムに対して複数の条件値を登録する条件" の場合は、全ての値が無効な場合にのみ無効と判断 され例外となります。@since 0.9.7.9
なお、サブクエリ自体は、ここで言う "一つのカラムに対して複数の条件値を登録する条件" には該当しません。例えば、InScopeRelation などは解釈次第でそのように受け取れますが、サブクエリの条件はあくまで "一つのカラムに対して別のクエリ(サブクエリ)を登録する条件" という扱いになります。(もちろん、サブクエリ内の一つ一つのそれぞれの条件には該当します)
