Why is Rails eager loading most of my database?

I have a highly-normalized user model called Respondent. It has many
join fields such as “ethnicity_id”, “education_id”, etc. that define
relational categories. Most of them are indexed. For reasons unknown,
Rails is hitting a huge number of the tables when accessing any
Respondent objects. For example, on a simple SHOW action:

==CONTROLLER== (from basic scaffold)
def show
@respondent = Respondent.find(params[:id])

respond_to do |format|
  format.html # show.html.erb
  format.xml  { render :xml => @respondent }
end

end

==VIEW== (note - nothing is even being rendered!)

<%= notice %>

<%= link_to ‘Edit’, edit_respondent_path(@respondent) %> |
<%= link_to ‘Back’, respondents_path %>

==RESULTING SERVER LOG==
Started GET “/respondents” for 127.0.0.1 at 2011-03-25 14:12:50 -0400
Processing by RespondentsController#index as HTML
Geokit is using the domain: localhost
←[1m←[35mPostalCode Load (101.0ms)←[0m SELECT postal_codes.* FROM
postal_codes
←[1m←[36mCountry Load (1.0ms)←[0m ←[1mSELECT countries.* FROM
countries←[0m
←[1m←[35mEthnicity Load (1.0ms)←[0m SELECT ethnicities.* FROM
ethnicities
←[1m←[36mEducation Load (0.0ms)←[0m ←[1mSELECT educations.* FROM
educations←[0m
←[1m←[35mJobStatus Load (0.0ms)←[0m SELECT job_statuses.* FROM
job_statuses
←[1m←[36mRespondent Load (0.0ms)←[0m ←[1mSELECT respondents.* FROM
respondents←[0m
Rendered layouts/_navigation.html.erb (1.0ms)
Rendered respondents/index.html.erb within layouts/application (190.0ms)
Completed 200 OK in 3809ms (Views: 205.0ms | ActiveRecord: 103.0ms)

==QUESTION==
Why in the world could the server need to hit these tables and why is it
taking so long? Some of these models are related – for example,
postal_code BELONGS_TO country, etc. It does not do this for any other
models. I have attached the model and migration file for reference since
they are so long.

On 25 Mar 2011, at 18:34, Taylor S. [email protected] wrote:

I have a highly-normalized user model called Respondent. It has many
join fields such as “ethnicity_id”, “education_id”, etc. that define
relational categories. Most of them are indexed. For reasons unknown,
Rails is hitting a huge number of the tables when accessing any
Respondent objects. For example, on a simple SHOW action:

Looks to me that it’s because of some of your validations, that seem to
be validating that (eg) ethnicity_id is in the list of all ethnicities
etc.

Fred

Hi Fred, thanks for the reply. Does rails execute validations when
simply showing the object? My assumption is that validations were only
called before_create.

Taylor

Thanks Fred - that was very helpful. Is there a more efficient way to
validate inclusion of that doesn’t tax the database so heavily?

On 25 Mar 2011, at 20:51, Taylor S. [email protected] wrote:

Hi Fred, thanks for the reply. Does rails execute validations when
simply showing the object? My assumption is that validations were only
called before_create.

The validations aren’t run, but when you do

validates_inclusion_of :foo, :in => bar

then ruby does have to evaluate all those arguments in order to call
validates_inclusion_of an setup the validation

Fred

Hi Fred, in Rails 3 I found validates_associated to be the most
streamlined approach for such a normalized model.

http://guides.rubyonrails.org/active_record_validations_callbacks.html#validates_associated

Thanks again!

On Mar 25, 9:50pm, Taylor S. [email protected] wrote:

Thanks Fred - that was very helpful. Is there a more efficient way to
validate inclusion of that doesn’t tax the database so heavily?

Well personally I’d just use a foreign key constraint, but you could
use validates presence of on the association

Fred