Support custom predicates in dialect

Hibernate ORM
1

We encountered a problem today where we wanted our queries to support the function CONTAINS for the HANA dialect with some appropriate mocking in an H2 dialect.

You can register custom functions, but the parser does not accept these as full expressions in a WHERE condition, meaning
SELECT … FROM … WHERE
CONTAINS(…),

which is the correct database syntax is not allowed by Hibernate, but
SELECT … FROM … WHERE
CONTAINS(…) = TRUE,

which is not correct for the database is allowed by Hibernate.

There appears to be a workaround for this where you render the function as “CONTAINS(…) AND TRUE” to make the second variant correct for the database.

Is better support for this type of custom function that is used as a full predicate planned?
There seem to be similar problems for CONTAINS and FREETEXT on SQL Server, so it is not just HANA.

I particularly don’t like that this encourages the HQL/JPQL queries to use a syntax that does not work anywhere and is only “fixed” in the renderer.

Best regards,
Richard

Related links:
https://docs.microsoft.com/en-us/sql/t-sql/queries/predicates?view=sql-server-2017
https://help.sap.com/viewer/4fe29514fd584807ac9f2a04f6754767/2.0.03/en-US/20f952437519101487edc3d9aba84238.html

2

You can create a new Jira issue for this, but it will be addressed in 6.0 since the parser was rewritten from scratch.

3

Thanks for the quick response. I posted this here rather than in Jira, because I feel this isn’t a bug, but more of a (from my perspective) sensible usecase that should be covered at some point.

Nice to know that 6.0 will come with a fresh parser. Are the “features” of the parser well-defined enough to predict if this could just work automagically or was your comment more of a hint that any changes involving the parser would have to wait at least for 6.x.

4

It’s definitely not a bug, but an enhancement request. I’m not very familiar with the work on 6.0, but since I’ve been told that the API has changed significantly, it makes sense to postpone such parser-related features until we have a release candidate.