Any update on HHH-17498?

Is https://hibernate.atlassian.net/browse/HHH-17498 on the roadmap for 6.5?

I am forced to maintain a custom version of NativeQueryImpl to workaround the problem which is not ideal.

There is no “roadmap” for bug fixes. We try to do our best and fix important bugs as soon as possible. Maybe it will be in ORM 6.5.0.Final, maybe in 6.5.1.Final or even later. The Hibernate ORM team has their own priorities and we can’t always focus on bugs. It’s an open source project after all, so if you care about something, consider getting involved and providing a fix yourself.

I agree and I do what I can to help.

As you can see from my comment on Feb 24 I supplied a possible implementation direction.

I don’t want to go through the effort of creating a PR if my implementation is not in sympathy with the project’s design goals.

We rejected support for this broken :parameterList is null or col in :parameterList also for HQL, because we don’t think this is a good solution that people should use. This approach confuses the query planners of many databases and often, this approach leads to more joins than necessary.

We recommend to use a query builder like e.g. the CriteriaBuilder if you need to construct dynamic filters.

In your particular case, you could make use of arrays, since Hibernate ORM supports that e.g.

where array_length(:parameterList) = 0 or array_contains(:parameterList, column)

and bind the values as e.g. Integer[].

While CriteriaBuilder or HQL queries might work with the minimalist example I provided, they will not work for queries that require the use of features and constructs those tools do not support.

At the end of the day automatically adding parentheses to native queries without regard to whether the targeted DB can support them universally and without a way to disable the functionality is a serious limitation to one of the most valuable features of the product.

If the solution I proposed in the ticket is acceptable I am willing to create the PR based on that solution.

they will not work for queries that require the use of features and constructs those tools do not support.

Then maybe tell us about those feature. Maybe you didn’t notice that a newer Hibernate ORM version added support for something or we can give you guidance for a workaround. At the very least, knowing which SQL features you’re looking for is going to help us understand what we should put our focus on.

At the end of the day automatically adding parentheses to native queries without regard to whether the targeted DB can support them universally and without a way to disable the functionality is a serious limitation to one of the most valuable features of the product.

I’m fine with adding some extra logic if you can detect this nicely, but you probably understand that this is a best effort thing. It’s hard to understand whether a list with parenthesis or just the plain parameter list should be used without parsing the full SQL in general.