jarinudom
commented
9 years ago I'd be down for including it, and the default should just be whatever log level puts it in development.log. I think it would be important to fix the squeel problem though first, or a lot of people are going to have their devlogs complaining at them unexpectedly.
Since I and many others now include Bullet by default when starting a new project, I wanted to ask this question here to get feedback on whether it's viable to include Bullet by default in future versions of Rails ActiveRecord.
Since starting Rails development I have seen N+1 mistakes from many juniors and a surprising number of intermediate developers. I have seen multiple live production apps ground to a standstill because of N+1 queries. I've seen extensively optimized apps with caching have major N+1 issues exist without the original developers having any idea what an N+1 query is. (And how should they know? It's not like rails is not giving them any indication that one exists.) Often the N+1 issue is only noticed after a project delivered to the client years ago slowly begins screeching to a halt because of the N+1 multipler.
Since N+1 problems are so deceptively easy to miss until significant amounts of data accumulates, I increasingly believe the idiom that "rails apps don't scale" is falsely linked to bad experiences with apps having N+1 query mistakes. To me it's a classic example of letting people shoot themselves in the foot without telling them why.
So my question is. Are Bullet's N+1 query warnings and unused eager loading warnings accurate enough to be worthy of inclusion as a default gem for development in Rails? Or is it common for developers to have valid use cases when using relational databases that would make default warnings from Bullet (even at the log level) overly intrusive?
Feedback appreciated!