Rails Conditional Eager Loading

Rails's eager loading (ScreenCast) is an important practice that saves some requests and queries when dealing with table relations in rails.
Up until now, using a condition hash to specify query was a little tricky if you use the eager loading method:
User.find(:all, :include => :jobs, :conditions => ["jobs.salary > ?",1000])

or using a hash (without eager loading)
User.find(:all, :conditions => {:name => 'eizesus'})

Using a conditions array/hash isn’t always my favorite way to write finds in Rails, but in certain cases must have when you deal with complex queries (like and "Advanced Search" feature).

In my current work,I needed to run conditions on an associated table in just such an "Advanced search" feature, so i came up with this simple and easy way to use a condition hash for eager loading methods:
User.find(:all, :include => :jobs, :conditions => {:name => 'eizesus', :jobs => {:position => 'Manager'})


or you can prepare the condition hash on the fly:
conditions = {}
conditions[:first_name] = params[:first_name] unless params[:first_name].blank?
conditions[:last_name] = params[:last_name] unless params[:last_name].blank?
conditions[:jobs] = {:position => params[:position]} unless params[:position].blank?

@users = User.find(:all, :conditions => conditions, :include => :jobs)


max indelicato:17 Distributed Systems and Web Scalability Resources

Well, scaling an application in my opinion, i like doing the dishes after a really big dinner, nobody wants to do it, but you have to.
Just leaving it there will only make the process of cleaning and washing the dishes worst, and might add some more problems on the way.
Max Indelicato stats in his blog a list of 17 Distributed Systems and Web Scalability Resources which makes it easier to understand and to implement a proper application scaling policy, and on time.

Rails Tip: Render, Better, JS Later

There are certain standards we got used too when creating rails views and layouts, which may cause a problem or some set backs to our applications.
We are all used to coding the JS includes way up in our document, moving the JS to the bottom of the page will render your page a little bit faster, and this is why.

When a browser reads a page, it goes through from the top to the bottom, So when we put the JS include's up, the browser will attempt to download them and hold the dom parsing until it finishes.

Rails Tip: AR eager loading and :select

The AR::Base.find support the options of :include (for adding associations as JOINs in the select) and :select (which pinpoints the columns you wish to select.
For some reason, it is impossible to do them both toghther for example

Article.find(:all, :include => :author, :select => 'authors.name')

This line will raise an exception.
Luckily, there is the select_with_include gem which enables this feature!

first, install the gem

gem install select_with_include

next, require it in your environment configuration file (or in environment.rb)

require 'include_with_select'

Now, you can use the :select option, remembering to use the table name even if a column name is not unique.
There is a single fault back, in case you want to select all the table columns, you need to write them all, one by one. yeah, it sucks.