Collections which are fetched AND restricted should not be written to second-level cache
Description
Attachments
- 22 Jul 2014, 06:44 AM
is duplicated by
Activity
Christian Beikov January 22, 2025 at 11:42 AM
As you can read in the comments, there are workarounds. It’s pretty simple though, don’t apply ON or WHERE clause restrictions for join fetched collections. It’s going to bite you one way or another.
Tom Schuller January 22, 2025 at 8:43 AM
any news on this?
Steve Ebersole August 7, 2024 at 10:44 PM
12 years and counting
18 years and yet not a single person has stepped up and implemented a fix for this oh-so critical issue
There is no good work around, except for disabling collection caching entirely.
That’s just not true. You can set the CacheMode for the query to ignore the cache:
final Book book = session
.createSelectionQuery( "from Book b left join fetch b.authors a where a.id = 1", Book.class )
.setCacheMode( CacheMode.IGNORE )
.getSingleResult();Bottom line, imo, it is a bad expectation for this to JutWork and I don’t think its super invasive to expect the user to set the cache-mode to IGNORE when they know they are fetching AND filtering the collection.
I’ll bring this up in the next dev meeting to see if anyone is willing to implement this. But I’m slightly against it given the overhead to determine whether this condition exists every time we parse a query.
Eric Fabian Martinez Rojas October 5, 2018 at 5:55 PM
12 years and counting
Martin L. May 16, 2017 at 9:12 AM
After 11 years (!!!) this issue is still present and caused a serious error in our released application. Please fix it.
Details
Details
Assignee
Reporter
Max Rydahl AndersenComponents
Priority
Major
enabling query caching for something like:
"select parent from Parent p inner join fetch p.children as pc where pc.somefield = :field"
will result in the "incomplete" collections to be stored resulting in subsequent lookups in the collection cache to be wrong.
Case #00010552