I’ve been having a lot of conversations via email with people using Searchlogic, that go like the following:

Some person: Hi Ben, How do I order by an order’s total with Searchlogic?

Me: Cache the total in your database. Your idol, Ben

Some person: Before Searchlogic, I was just doing: Order.all(:order => “(quantity * price) ASC”). Is there a way to do this in Searchlogic?

Me: No, you shouldn’t order data like that. …long explanation of what to do…. Your idol, Ben

Some person: Thank you so much Ben, I can’t thank you enough for everything you have done for me. You truly are my idol. There should be a statue in your honor.

Maybe it didn’t go exactly like that, but you get the point. So instead of having to retype the “long explanation of what to do”, I can just link them to this post:

This can be simple or complicated depending on how you calculate your total. Let’s start with the simple:

Simple solution

Your total method looks something like to following. Dealing with only local attributes.

def total
    quantity * price
end

Your first thought might be to sort via the ruby sort method. This is wrong on so many levels, not to mention you already have a tool that is extremely good at sorting data: your database.

Awesome! We’ll just do something like this:

Order.all(:order => "(quantity * price) ASC")

Wrong again! This is bad for a number of reasons:

1. Your code is no longer DRY. What if you want to add in tax later on down the road? You’ll have to do it in multiple places.
2. (quantity * price) can not be indexed. The whole point of indexing is to sort.

Now you’re saying “WTF Ben?!?!?1!?11″. Relax, why not just cache the total in the database?

class Order < ActiveRecord::Base
    before_validation :cache_virtual_columns

    def total
        quantity * price
    end

    private
        def cache_virtual_columns
            self.total = total
        end
end

Now you can index the total column and order just like you would with any other column. Yay!

Don’t celebrate yet. Chances are your total probably isn’t that simple.

Advanced solution

Maybe your total method looks like:

def total
    line_items.sum(:total) + tax + shipping_cost
end

Oh no! What happens when the total of a line item changes? The total in the orders table is no longer accurate. Your total now depends on other models. This is where observers shine:

class OrderObserver < ActiveRecord::Observer
  observe :order, :line_item

  def before_validation(obj)
    case obj
    when Order
      obj.total = obj.total
    end
  end

  def after_save(obj)
    case obj
    when LineItem
      obj.order.update_attribute(:total, obj.order.total)
    end
  end
end

You could really set this up a number of ways. You could create a CacheObserver that handles all caching for all models. This could get messy and confusing really fast, which is why I recommend the above example. My philosophy on OO programming is that classes should be responsible for their self. If the Order class is calculating the total it should be responsible for keeping it up to date in the database too.

“But Ben, this looks messy and complicated”. I agree with you, to an extent, but there is no simple solution here, because there is no pattern. Your total method could be anything you want. For all I know, your total method could be outsourced to a team in India that calculates the total by hand.

Sometimes in programming you have to give up something to gain something. I feel like writing some simple code in an observer is worth having a cached value of the total in the database. It makes everything so much cleaner, easier, and simpler in your controllers and views. Models should do all of the heavy lifting anyways.

Obviously, this is not just limited to total. You could do this for pretty much any virtual attribute in your models.

What do you think? I am always interested in feedback.