Hi,

I need 'special case' org.hibernate.criterion.Criterion implementation that will NOT evaluate to any sql expression and will NOT create additional AND entry (or other) in output SQL.

The reason of this is that I want to get rid of all the conditional logic with assembling Criteria. e.g:



In future we can create a Criterion hierarchy that may check if given value is null, and if so, don't evaluate to any sql fragment.

For now, 'special case' Criterion is enough since you can arrange your code and get rid of null checking conditional logic, creating 'special case' criterion when is needed.

Or perhaps there is already something similar in Hibernate?

Thanks,
Szczepan

You could have a look at Example queries.

http://www.hibernate.org/hib_docs/v3/re ... a-examples

By default it uses only the not-null properties.

e.g.

UserProfle userProfile = new UserProfile();
userProfile.setLastName(lastName);
.
.
userProfile.set...


userProfileCriteria.add(Example.create(userProfile));

However, if ALL the properties in userProfile object are null then you would get an extra condition "and (1=1)" in the output SQL, otherwise only the not-null properties are included.

Nice workaround :)))

Still, I want to avoid the (1=1) entry. I've allready created similar solution (stubbing Criterion with 1=1 implementation) but I don't like it.

I am thinking about a patch but I can't get to mailing list yet...

what is wrong with "(1=1)" ?

1. Are you sure that every jdbc vendor provides implementation smart enough to remove supid clause fragment prior to execution of a query (performance concern)? Some database engines may even throw an exception (or have a mode that acts this way) when query fragment is unnecessary.

2. Looks awful in logs, just unprofessional.

3. If I create IgnorableCriterion that evaluates to 1=1, the class that creates where clause adds 'and' joins automatically. So the output may be like: 1=1 and 1=1 and 1=1 and 1=1 ....

The question is what's the big deal to change it? It's just adding Special Case Criterion that evaluates to nothing and single type check in class that creates where clause.

Not mentioning more robust solutions -> refactoring Restrictions from static class to genuine object with setIgnoreNulls() method or refactoring to hierarchy. That will dramatically reduce amount of conditional logic in every piece of code that uses criteria API. Delibrate null comparisons are very rare in search criteria implementations.

1. don't use non-smart vendors ;)

2. well, maybe.

3. ...

..no don't do type checking for this. should be some polymorphic/behavioral thing.

Patches can be added to our jira, but please add a testcase to show its purpose.