Comment by sanderjd | Hacker News Reader

Comment by sanderjd | Hacker News Reader

Parent Full thread

On the third point, my sense is that the part of AR that is often expensive is building full objects, when you often only need a few of their attributes. This is not such a big deal with a single (or a few) `find`s, but often is when you're grabbing lots of records, even when using `includes` properly. I find myself using `pluck` frequently when tracking down performance issues.

I often wish for a pared down database interaction API (I hesitate to call it an ORM) that just exposes raw data, and provides a convenient query interface (like AR does, but also like raw arel). Maybe this is what Sequel does, and I should be using that, I'm not sure. I was excited about datamapper2 and I've looked at ROM[0], but I'm not sure it's what I'm dreaming of. I could probably cobble it together by using existing database driver gems and arel directly. Unfortunately, as is usually the case when considering venturing off the beaten path of Rails, this sort of thing would give up a lot of the "conventions" advantages of Rails. AR pretty much is Rails.

[0]: http://rom-rb.org/

That is, indeed, what Sequel does. You can query the database object directly (for example, `DB[:posts].where{comments_count > 5}.exclude(poster_name: "Bob").order(:comments_count.desc).limit(10).all`) and get back an array of hashes.

Sequel's model layer is also faster than ActiveRecord's, because much of the additional functionality that ActiveRecord piles onto all records (dirty tracking, single table inheritance, etc.) are available in Sequel via a plugin system. You can enable the plugins you want to use and not pay the overhead of all the others. You can even enable specific plugins for only the models where you'll actually want to use them.

It also has a lot less magic (no association proxies, unless you enable the plugin for them :)), ridiculously customizable (many more options for associations, custom eager loading logic, and so on), and has an implementation of its Postgres adapter written in C for performance.

Highly, highly recommended.

Edit: Oh, and an issue tracker that is almost always at zero, with a very fast response time. As someone who has contributed a patch to ActiveRecord, I can't tell you how nice that is.

Yeah, that does sound like exactly what I want. Still has the "conventions" problem I mentioned, but maybe worth it, and common enough that it isn't that big a deal.

To your edit: Ha, I have a PR against arel that is similarly neglected[0]. Maybe an advantage of using a less popular library is that the maintainers aren't so overwhelmed that things get lost in the shuffle!

[0]: https://github.com/rails/arel/pull/320

   On the third point, my sense is that the part of AR 
   that is often expensive is building full objects, 
   when you often only need a few of their attributes.

This totally correct in my experience.

Reply on news.ycombinator.com