3 ms·
This is very similar in Rails. Only in Rails it is far easier to accidentally introduce interfaces that do this: the downside of having a very easy DSL to quic
by berkes 6y ago
This is very similar in Rails.
Only in Rails it is far easier to accidentally introduce interfaces that do this: the downside of having a very easy DSL to quickly add relations between records/tables is that people very quickly add relations between records/tables: introduce spaghetti.
And in Rails it is very hard to debug, because ActiveRecord tries hard to be smart, but this "smart" quickly degrades into "black magic" when stuff gets complex (mostly caused by: see above, in my experience).
Edit: currently working on a codebase where 3000ms queries to get 200 items is no exception, where 500+ queries to build a page is common and where, if you change a foo on a bar, suddenly at the other end of the app, your blargs and blazzes start blurping out SQL that used to run 200ms but now adds some wheres and limits and group-bys that make it run over 2000ms. Yay for Rails trying to help!/s
- dwheeler 6y agoYou might check out the gem "fasterer" which warns about n+1 queries.
- berkes 6y agoWe use bullit, and scoutAPM. So we are well aware of N+1 queries. Edit: but thanks for the suggestion. Will have a look if it works better than bullit. There's a difference, however, between being aware of them and fixing them. Especially when they were caused by an unrelated change; when you cannot just roll back that change.