5 ms·

Activerecord is flaw because of n+1 query issue.

by revskill 2y ago

cpursley 2y ago
I also dislike Activerecord. The solution to a lot of this is creating database views and interfacing with that.
rtcoms 2y ago
Just use ActiveRecord's`find_by_sql` method
- revskill 2y ago
  The problem is it's a pain to debug through the call chain a.b.c.d.e to figure out where's the cause.
Alifatisk 2y ago
Use `includes` and it's solved, you make it sound like a huge deeply rooted issue, it's not. Anyone can achieve n+1 issue with whatever tool they use, it's not ActiveRecord specific.
- revskill 2y ago
  Only with ActiveRecord pattern you need such kind of hacks to prevent, it's why it's flaw.
  - freedomben 2y ago
    `includes` is not a hack. Clearly you prefer implicit over explicit when it comes to SQL generation. That's your prerogative, but I strongly disagree. I don't want the ORM trying be clever on me because it is opaque and complex. I want it to use the function arguments to construct a query, and nothing else. Debugging long-running queries is already complex enough without "clever" code trying to abstract it all away from me. Some things should not be abstracted way. It feels nice when your database is small, but it cuts hard when you start to scale.
    - revskill 2y ago
      No u need includes because when u do a.b.c u forgot to includes. It is the api problem for letting u chaining the related objects without including it.
  - Alifatisk 2y ago
    Hibernate has `JOIN FETCH()`, Django has `select_related()`, Entity has `Include()` and so on ...
izietto 2y ago
Very much addressed by tools like bullet, prosopite, strict_loading and others
jeffmess 2y ago
[flagged]
- Alifatisk 2y ago
  Nooo, don't be derogatory
pugio 2y ago
n+1 queries can be solved in many different ways – you can easily do`User.all.includes(:character_sheet)` for example, to perform just 2 queries: 1 for users, 1 for their character sheet. The nice thing about first-class production sqlite support is that even if you do end up with n+1 queries, it's not as big a deal: https://www.sqlite.org/np1queryprob.html https://www.sqlite.org/np1queryprob.html Certainly I wouldn't care about it while prototyping. I can always go back and optimize queries with judicious `.joins()` or `.includes()` if it becomes a bottleneck.
- ElatedOwl 2y ago
  I spent 10 years doing C#, and the last 3 doing Ruby. I never thought of N+1 as that big of an issue. These queries are typically fast (1ms * 100 is still only 100ms…) and multithreaded web servers are non blocking on IO like database calls. But these sporadic elevated response times kept showing up on endpoints, where they’d be hundreds of milliseconds slower than normal, but by some extension of 100ms. Say, normally 5ms, now taking 105ms, or 505ms, or more. Then I learned about ruby’s non parallel but concurrent model, where within a process only one thread can execute at a time. In most workloads you’ll hit IO quickly, and the threads will play nicely. But if you have a CPU crunching exercise, it’ll delay every other thread waiting to execute by 100ms before it preempts. Now consider you’re doing 10 1ms queries inter process with a greedy thread, and you’re waiting at minimum 1010ms. Still love Ruby but the process model gave me a reason to hate N+1s.
  - chris12321 2y ago
    Since Rails 7.1 we've had https://www.rubydoc.info/github/rails/rails/ActiveRecord%2FRelation:load_async https://www.rubydoc.info/github/rails/rails/ActiveRecord%2FR... which actaully does run queries in parallel. There's also Rails' russian doll caching, which can actaully results in pages with n+1 queries running quicker than ones with preloaded queries. https://rossta.net/blog/n-1-is-a-rails-feature.html https://rossta.net/blog/n-1-is-a-rails-feature.html
    - ElatedOwl 2y ago

Activerecord is flaw because of n+1 query issue.

cpursley 2y ago

I also dislike Activerecord. The solution to a lot of this is creating database views and interfacing with that.

rtcoms 2y ago

Just use ActiveRecord's`find_by_sql` method

revskill 2y ago
The problem is it's a pain to debug through the call chain a.b.c.d.e to figure out where's the cause.

Alifatisk 2y ago

Use `includes` and it's solved, you make it sound like a huge deeply rooted issue, it's not. Anyone can achieve n+1 issue with whatever tool they use, it's not ActiveRecord specific.

revskill 2y ago
Only with ActiveRecord pattern you need such kind of hacks to prevent, it's why it's flaw.
- freedomben 2y ago
  `includes` is not a hack. Clearly you prefer implicit over explicit when it comes to SQL generation. That's your prerogative, but I strongly disagree. I don't want the ORM trying be clever on me because it is opaque and complex. I want it to use the function arguments to construct a query, and nothing else. Debugging long-running queries is already complex enough without "clever" code trying to abstract it all away from me. Some things should not be abstracted way. It feels nice when your database is small, but it cuts hard when you start to scale.
  - revskill 2y ago
    No u need includes because when u do a.b.c u forgot to includes. It is the api problem for letting u chaining the related objects without including it.
- Alifatisk 2y ago
  Hibernate has `JOIN FETCH()`, Django has `select_related()`, Entity has `Include()` and so on ...

izietto 2y ago

Very much addressed by tools like bullet, prosopite, strict_loading and others

jeffmess 2y ago

[flagged]

Alifatisk 2y ago
Nooo, don't be derogatory

pugio 2y ago

n+1 queries can be solved in many different ways – you can easily do`User.all.includes(:character_sheet)` for example, to perform just 2 queries: 1 for users, 1 for their character sheet. The nice thing about first-class production sqlite support is that even if you do end up with n+1 queries, it's not as big a deal: https://www.sqlite.org/np1queryprob.html https://www.sqlite.org/np1queryprob.html Certainly I wouldn't care about it while prototyping. I can always go back and optimize queries with judicious `.joins()` or `.includes()` if it becomes a bottleneck.

ElatedOwl 2y ago
I spent 10 years doing C#, and the last 3 doing Ruby. I never thought of N+1 as that big of an issue. These queries are typically fast (1ms * 100 is still only 100ms…) and multithreaded web servers are non blocking on IO like database calls. But these sporadic elevated response times kept showing up on endpoints, where they’d be hundreds of milliseconds slower than normal, but by some extension of 100ms. Say, normally 5ms, now taking 105ms, or 505ms, or more. Then I learned about ruby’s non parallel but concurrent model, where within a process only one thread can execute at a time. In most workloads you’ll hit IO quickly, and the threads will play nicely. But if you have a CPU crunching exercise, it’ll delay every other thread waiting to execute by 100ms before it preempts. Now consider you’re doing 10 1ms queries inter process with a greedy thread, and you’re waiting at minimum 1010ms. Still love Ruby but the process model gave me a reason to hate N+1s.
- chris12321 2y ago
  Since Rails 7.1 we've had https://www.rubydoc.info/github/rails/rails/ActiveRecord%2FRelation:load_async https://www.rubydoc.info/github/rails/rails/ActiveRecord%2FR... which actaully does run queries in parallel. There's also Rails' russian doll caching, which can actaully results in pages with n+1 queries running quicker than ones with preloaded queries. https://rossta.net/blog/n-1-is-a-rails-feature.html https://rossta.net/blog/n-1-is-a-rails-feature.html
  - ElatedOwl 2y ago