So what are the other approaches (if any) to solve this n+1 issue? In the past I've read some articles here and there listing some approaches, but they just glossed over it and I also pretty much forgot them all. Would be best if there's an overview of the ways 😁
That's more a workaround than an alternative. (@)BatchSize always requires additional queries. Depending on your (@)BatchSize configuration and the size of the relationship, this might be more than 1 additional query.
Good question. I'm currently concentrating on the Persistence Hub (thorben-janssen.com/join-persistence-hub/), and I don't have the time to write an entire book. Maybe I reconsider that next year. But then the book would be about Hibernate 7 (or maybe 8) :)
I'm currently very busy with clients and the Persistence Hub. If I write a new book, it will be about Hibernate 7 (currently in "release candidate" state) or 8.
The end of n+1 select issues - not so fast. As soon as you add a limit, offset to do pagination, hibernate will pull the ENTIRE resultset in memory and do the aggregation in memory. I know you know this problem because I have read a bunch of articles from you on this. The recommendation from you on those articles iirc is to use two queries, one to fetch only ids of the entity root and second to actually fetch the fully hydrated entity graph. That's the solution I have been using in my own production code base.
No, I'm not :) I just liked the picture and thought that the almost endless row of pillars matched the queries in the n+1 select issue. I wasn't aware it was the picture of a mosque.
![KSI - Dirty [Official Visualiser]](http://i.ytimg.com/vi/VoDh1h1dPUE/mqdefault.jpg)
Thx for the fantastic videos
Thanks for watching, Paul!
thanks for taking your time to educate us
happy to help
So what are the other approaches (if any) to solve this n+1 issue?
In the past I've read some articles here and there listing some approaches, but they just glossed over it and I also pretty much forgot them all. Would be best if there's an overview of the ways 😁
I'll talk about the other one in the next video 😁
I'll publish it next week
Have a look at @BatchSize
@BatchSize
That's more a workaround than an alternative.
(@)BatchSize always requires additional queries. Depending on your (@)BatchSize configuration and the size of the relationship, this might be more than 1 additional query.
As always, thanks for the excellent material. When you plan to release a book about hibernate 6?
Good question.
I'm currently concentrating on the Persistence Hub (thorben-janssen.com/join-persistence-hub/), and I don't have the time to write an entire book. Maybe I reconsider that next year. But then the book would be about Hibernate 7 (or maybe 8) :)
I'm currently very busy with clients and the Persistence Hub. If I write a new book, it will be about Hibernate 7 (currently in "release candidate" state) or 8.
Thanks
Thanks for watching
The end of n+1 select issues - not so fast. As soon as you add a limit, offset to do pagination, hibernate will pull the ENTIRE resultset in memory and do the aggregation in memory.
I know you know this problem because I have read a bunch of articles from you on this. The recommendation from you on those articles iirc is to use two queries, one to fetch only ids of the entity root and second to actually fetch the fully hydrated entity graph. That's the solution I have been using in my own production code base.
That's one of the pitfalls I'll talk about in this week's video :)
Are you muslim ?? At 1:43 I noticed the background of a mosque.
No, I'm not :)
I just liked the picture and thought that the almost endless row of pillars matched the queries in the n+1 select issue. I wasn't aware it was the picture of a mosque.
@Thorben-Janssen ohh okay. That's very thoughtful