>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,...
>When your DB or cloud service gives you a printout of your 10 slowest queries, you then have to figure out what object code that relates to
Not if you have proper telemetry set up... Tooling like instana was extremely useful for me to diagnose exactly where SQL statements caused issues
>Extra magic: if you've read a class from the db, pass it around, and then modify a field in that class, will that perform a db update: now? later? never?
For hibernate if you understand the concepts of:
- application level repeatable reads
- it's dirty checking mechanism
- when the session is flushed / entity lifecycle
That 'magic' isn't magic anymore. But every abstraction is leaky (even SQL)
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,...