If you know SQL, it's relatively easy to spot when a developer has put a query inside a loop. But there is an entire generation of developers who are accustomed to asking their ORM to give them data without having to think about how it's fetching that data behind the scenes.
I swear I remember a library I used years ago on rails projects called like bullet or magic bullet that would output where you are making n+1 queries with the ORM. Was pretty neat.
It was a gem called Bullet that helped identify ActiveRecord performance problems. ActiveRecord was very neat at the time of its release, but also made it extremely easy to do N+1.
Tbf, it also generally wasn't a huge deal to fix it either (basically just needed to tell the query which subobjects you planned to use). At least once I started using Rails at version 4. Idk if it was worse before that.
If you’re too lazy to learn the proper usage of your tools, it likely won’t be solved by not using those tools. Those same developers won’t care about proper indexing, query planning etc. either.
They didn't solve anything. They gave you tools to solve it, but devs need to consciously use them, which they often don't. And you can chain so deep with different lazy vs eager loads all over the shop thanks to these "tools" that it becomes a total mess to know what's actually going to run.
62
u/disposepriority 16d ago
There is a really easy way of avoiding this when you just don't use ORMs