# Any update on HHH-17498?
**URL:** https://discourse.hibernate.org/t/any-update-on-hhh-17498/9408
**Category:** Hibernate ORM
**Created:** [April 23, 2024, 3:16pm UTC](https://discourse.hibernate.org/t/any-update-on-hhh-17498/9408 "2024-04-23T15:16:36Z")
**Posts on this page:** 6
**Page:** 1
### Author:  [@Jeff\_Maxwell](https://discourse.hibernate.org/u/Jeff_Maxwell)
#### Post date: [April 23, 2024, 3:16pm UTC](https://discourse.hibernate.org/t/any-update-on-hhh-17498/9408/1 "2024-04-23T15:16:36Z")
Is [https://hibernate.atlassian.net/browse/HHH-17498](https://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.
---
### Author:  [@beikov](https://discourse.hibernate.org/u/beikov)
#### Post date: [April 23, 2024, 5:02pm UTC](https://discourse.hibernate.org/t/any-update-on-hhh-17498/9408/2 "2024-04-23T17:02:22Z")
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.
---
### Author:  [@Jeff\_Maxwell](https://discourse.hibernate.org/u/Jeff_Maxwell)
#### Post date: [April 25, 2024, 4:59pm UTC](https://discourse.hibernate.org/t/any-update-on-hhh-17498/9408/3 "2024-04-25T16:59:14Z")
I agree and I do what I can to [help](https://github.com/hibernate/hibernate-orm/pulls?q=+author%3Ajmax01+).
As you can see from my [comment](https://hibernate.atlassian.net/browse/HHH-17498?focusedCommentId=114221) 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.
---
### Author:  [@beikov](https://discourse.hibernate.org/u/beikov)
#### Post date: [April 26, 2024, 12:03pm UTC](https://discourse.hibernate.org/t/any-update-on-hhh-17498/9408/4 "2024-04-26T12:03:13Z")
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[]`.
---
### Author:  [@Jeff\_Maxwell](https://discourse.hibernate.org/u/Jeff_Maxwell)
#### Post date: [April 26, 2024, 7:45pm UTC](https://discourse.hibernate.org/t/any-update-on-hhh-17498/9408/5 "2024-04-26T19:45:26Z")
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.
---
### Author:  [@beikov](https://discourse.hibernate.org/u/beikov)
#### Post date: [April 29, 2024, 9:24am UTC](https://discourse.hibernate.org/t/any-update-on-hhh-17498/9408/6 "2024-04-29T09:24:47Z")
> 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.