Query on field collection return null entities when having a cache hit.
Example of query:
In real world application, we are unable to babysit each query. Expert usually enable query cache on all queries and cache on all entities.
Using example above, query cache on Manager works, and one day one of the many dozen developers add a query against a field collection. It works in the beginning because not used in a complex scenario so we don't have a second call occurring and so no cache hit. Then one day, in production with data changes, we got a cache hit, and the return value is a null entities and the application crash or the logic/data get corrupted.
Two options here, and maybe the first option could be a short time solution while you are working the a long term solution:
1- Detect at runtime that the query is against a collection field and then bypass any query cache hit.
2- Fix the logic so that query cache can work with collection field
See attachment for a simple use case failing.
, as I said on a [comment|https://hibernate.atlassian.net/browse/HHH-4297?focusedCommentId=101128&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-101128) on HHH-4297, the query you are using is not valid.
The attached test passes if the following invalid query:
select m.employees from Manager m
is changed to a valid query:
select e from Manager m join m.employees e
Feel free to open an "Improvement" issue that will throw an exception to disallow your use case.
Hibernate return correct value with: "select m.employees from Manager m" as shown in the provided use case.
Are you telling me it's returning correct value even if it's not supported? And I should open an enhancement request to get this blocked?
Or you are telling me that some query are supported to return values but NOT supported to be Query Cached?
Any documentation about any of this?
For example, if I create a Named Query that is marked to be cacheable I would think the official expectation is to throw an exception at initialization if it's not a valid use case.
At the end of the day the query make sense and to be cacheable make sense, so it could also be an enhancement request.
I have attached a workaround using AspectJ aspect. The patch make sure to bypass query cache to not get any null entity when we see such query.