コードが少ないことを除けば、Hibernate Criteria APIを使用してIN句を作成する次の2つのアプローチの違いは何ですか?パフォーマンスの問題はありますか?検索に欠落しているロジックはありますか?行が返される限り、どちらも同じように動作します。
Disjunction disj = Restrictions.disjunction();
for (String value : stringArray) {
disj.add(Restrictions.eq("code", value));
}
where.add(disj);
VS.
Restrictions.in("code", stringArray);
私が尋ねる理由は、前者が存在するレガシーコードをリファクタリングしているためですが、後者を期待していました。両方が同じである場合は、レガシーコードをそのままにします。
Hibernate Disjunction を使用して
Group expressions together in a single disjunction
つまり、値と比較する必要がある場合X OR Y OR Zconditionally、反復して適用することができます 選択的選言
したがって、理想的には Restrictions.in および Restrictions.Disjunction が同じことを行うので、この場合は前者を優先します。
Restrictions.Disjunctionは、明示的な制御を提供します。たとえば、like演算子は許可されますが、in演算子は許可されません。
例えば:
criteria.add(Restrictions.disjunction()
.add(Restrictions.eq("bill.stateCd", null))
.add(Restrictions.eq("bill.stateCd", ""))
.add(Restrictions.ilike("bill.stateCd","%"+stateCd+"%")));
で達成できません
criteria.add(Restrictions.in("bill.stateCd", Arrays.asList(null,"", "%"+stateCd+"%")));
指定されたコードでは、stringArray
に要素がゼロの場合、これら2つは非常に異なる動作をします。
ゼロ式で選言を使用すると、1=1
または同等のものを使用した有効なSQLクエリが生成されます。
Restrictions.in
は、値のないIN演算子につながります。これは、多くの場合(おそらく一部のSQL方言で処理できますが)構文的に正しくありません。