Hibernate Restrictions.in vs. Disjunction

Question

Other than less code, what is the difference between the following two approaches to building an IN clause using the Hibernate Criteria API? Are there performance concerns? Is there some logic in the retrieval I am missing? They both seem to perform the same as far as rows returned.

Disjunction disj = Restrictions.disjunction();
for (String value : stringArray) {
     disj.add(Restrictions.eq("code", value));
}
where.add(disj);

VS.

Restrictions.in("code", stringArray);

The reason I ask is because I am refactoring legacy code where the former exists, but I was expecting the latter. If they are both the same, I am going to leave the legacy code alone.

Glazed

Answer 1

Hibernate Disjunction is used to

      Group expressions together in a single disjunction

which means, if you have to compare against values X OR Y OR Z conditionally, you may iterate over and apply selective disjunction

So ideally in your case Restrictions.in and Restrictions.Disjunction does the same thing, i prefer the former in this case.

Calcific

Seems like the 2nd approach is more concise, with no need for looping. Your explanation makes sense, though. Thank you. – Glazed

@sma: when i say former, i was referring to the 1st(Restrictions.in) in my post, and not your post :) – Calcific

Answer 2

Restrictions.Disjunction gives us explicit control , for example it allows like operator, where as in operator does not .

For example:

criteria.add(Restrictions.disjunction()
                        .add(Restrictions.eq("bill.stateCd", null))
                        .add(Restrictions.eq("bill.stateCd", ""))
                        .add(Restrictions.ilike("bill.stateCd","%"+stateCd+"%")));

cant be achieved with in

criteria.add(Restrictions.in("bill.stateCd", Arrays.asList(null,"", "%"+stateCd+"%")));

Crossbar

Answer 3

With the given code those two behave very differently when stringArray does have zero elements.

Using Disjunction with zero expressions produces valid SQL query with 1=1 or equivalent.

Restrictions.in leads to IN operator without values, which is often (maybe some SQL dialect can handle it though) syntactically incorrect.

Ormazd