kitchen catalogs
New Member
Hibernate's \[code\]Criteria\[/code\] API has \[code\]Restrictions.ilike\[/code\] function which has the following contract:\[quote\] A case-insensitive "like", similar to Postgres ilike operator\[/quote\]That's cool. But the same class also has \[code\]like\[/code\] function, having much more vague contract:\[quote\] Apply a "like" constraint to the named property\[/quote\]As far as I imagine, this just translates into "SQL LIKE". And the problem with SQL \[code\]LIKE\[/code\] is that it's behaviour differs from database to database. For example, it is case sensitive on Postgres but case insensitive on MySQL.Questions:
- Should Hibernate really expose an API method which is database specific? In other words, what's the point of having \[code\]Restrictions.like\[/code\] as it does not provide any guarantees? As a minimum, should there not be a warning in the method Javadoc?
- Is there a way to do case-sensitive prefix matching in Hibernate (or at least raw SQL)? For example, if there are two rows having strings \[code\]'foo1'\[/code\] and \[code\]'foO1'\[/code\], query against prefix \[code\]'foo'\[/code\] would only match the former, but not latter and be database independent?