Topic: Rails Purity vs Efficiency

In my application I frequently come across the issue listed in the title.

Consider the following:

class Booking < ActiveRecord::Base
    belongs_to :resource
end

class Unavailability < ActiveRecord::Base
    belongs_to :resource

    def self.unavailability_exists?(booking)
        #option1
        find_by_resource_id(booking.resource_id)
       
        #option2
        find_by_resource_id(booking.resource.id)
    end
end


The difference between option1 and option2 is seemingly trivial.  The readability seems just about the same('_' vs '.')  The efficiency is the difference of a possible database query(depending if the booking object had previously cached the association).  In practice, the addition of one extra query to the db could become significant if looping through thousands of Bookings.  You might ask, why go at all with option2?  Well, in my case, resource_id isn't just "resource_id" its a long drawn out name that makes the code harder to read.  I feel "booking.resource.id" is certainly more "pure". 

Another example is my colleague who loves doing raw sql queries as opposed to associations.  His code is definitely more efficient(consider a query joining 3 tables vs. rails doing a query, getting the id, query again with that id, and so on...)

There are definitely criticisms on the way I'm doing the above code, but hopefully you'll see the point I'm trying to raise.  If anything is unclear let me know.  I'm interested in how and when people choose efficiency over rails purity.

~S

Re: Rails Purity vs Efficiency

Synth wrote:

Another example is my colleague who loves doing raw sql queries as opposed to associations.  His code is definitely more efficient(consider a query joining 3 tables vs. rails doing a query, getting the id, query again with that id, and so on...)

The :include parameter in a find allows you to join models together in a single query so you don't need to do raw SQL to do this. But, a raw SQL query does definitely give you more control to optimize when you need to.

I recommend going the purity/readability route first, then do some major stress testing when the project nears launch. I can then optimize any bottlenecks which I may come across.

That said, in the case of the example code I would probably go with option 1, as the readability is identical. If the resource_id foreign key is actually longer and harder to read, I think this calls for a column rename.

However, I think this code belongs in the booking model:

class Booking < ActiveRecord::Base
  belongs_to :resource

  def self.unavailability
    Unavailability.find_by_resource_id(resource_id)
  end

  # or even more pure assuming resource has_one unavailability
  def self.unavailability
    resource.unavailability
  end
end


There's actually quite a bit of options when optimizing: caching, including models in the query, etc. If you try to do pre-optimization, you will be guessing what will need optimization and probably end up with code that's harder to read. This is why it is better to wait and find the bottlenecks later so you know exactly what needs to be optimized.

Railscasts - Free Ruby on Rails Screencasts

Re: Rails Purity vs Efficiency

As a new rails developer(~4months fulltime), I opt for purity in my code as well.  Otherwise, I might as well go back to the "archaic" days of php.  Its just that my coworker is always nagging me about the efficiency, and its getting on my nerves!

In any case, changing the column is a no go as I've got legacy code to deal with.  But I suppose I can always create attr_accessors that shorten it up right?