>That's what the N+1 query problem is. Business logic shouldn't have to know that certain attributes will cause database queries.
I really don't get these arguments because in some form or another, ALL abstractions are leaky.
Example:
A novice developer might write a @OneToMany in hibernate without knowing the internals of the abstraction, causing n+1 problems. Two paths forward:
1. blame the abstraction
2. Learn (some) internals of the abstraction in order to use it correctly: dont do eager fetching, use join fetches, ... ( There's also tooling like hypersistence optimizer, digma, jpabuddy that comes to mind)
And by that same logic, would you berate somebody writing 'plain SQL' which - when expected with the query plan - turns out to be a very unperformant query?
Again, two options:
1. blame the abstraction
2. Learn (some) internals of the abstraction: analyze the query plan, perhaps write some indexes,...
I really don't get these arguments because in some form or another, ALL abstractions are leaky.
Example:
A novice developer might write a @OneToMany in hibernate without knowing the internals of the abstraction, causing n+1 problems. Two paths forward:
1. blame the abstraction
2. Learn (some) internals of the abstraction in order to use it correctly: dont do eager fetching, use join fetches, ... ( There's also tooling like hypersistence optimizer, digma, jpabuddy that comes to mind)
And by that same logic, would you berate somebody writing 'plain SQL' which - when expected with the query plan - turns out to be a very unperformant query?
Again, two options:
1. blame the abstraction
2. Learn (some) internals of the abstraction: analyze the query plan, perhaps write some indexes,...