使用include中嵌Hash取出一个多层次的对象关联数据

使用include中嵌Hash取出一个多层次的对象关联数据.

首先有如下关系:

project issue  : 一对多
issue comment : 一对多
comment history : 一对多
Project ［1］ <---- [n] issue (1) <---- (n) comment [1] <---- [n] history

class Project
  has_many :issues
end

class Issue
  belongs_to :project
  has_many :cccc      # cccc  为了区别后面的名称不致混淆

#在issue中创建一条与之对应的comment,这里用实例变量为了方便在issue保存的时候也一同保存comment的信息。
  def init_comment(content = "")
    @current_comment ||= Comment.new(:resource => self, :creater => current_user, :content => content)
    @issue_before_change = self.clone
    @current_comment
  end

#issue保存的时候一同保存comment，以及histories的信息。
##这里需要注意的是，要保证histories表中的comment_id(histories表中与comment关联的外键) `comment_id` int(11) default '0', 必需设置一个默认值，否则将不能保存comment 和 history的信息。
  def before_save
    if @current_comment
      # attributes changes
      (Issue.column_names - %w(id content resource_id resource_type)).each {|c|
        @current_comment.histories << History.new(:property=>c,
                                                  :comment => @current_comment,
                                                  :old_value => @issue_before_change.send(c),
                                                  :value => send(c)) unless send(c)==@issue_before_change.send(c)
      }
      @current_comment.save
    end
    # Save the issue even if the comment is not saved (because empty)
    true
  end

end

class Comment
  belongs_to :issue
  has_many :histories
end

class History
  belongs_to :comment
end

一条语句实现取出这其中的所有记录：

Project.find(:first,:include =>[{ :issue => { :cccc => { :histories => :comment }}}]
注意，include中的关联的名称要对应好。

API 中的相关使用介绍
To include a deep hierarchy of associations, use a hash:

  for post in Post.find(:all, :include => [ :author, { :comments => { :author => :gravatar } } ])

That‘ll grab not only all the comments but all their authors and gravatar pictures. You can mix and match symbols, arrays and hashes in any combination to describe the associations you want to load.

All of this power shouldn‘t fool you into thinking that you can pull out huge amounts of data with no performance penalty just because you‘ve reduced the number of queries. The database still needs to send all the data to Active Record and it still needs to be processed. So it‘s no catch-all for performance problems, but it‘s a great way to cut down on the number of queries in a situation as the one described above.

Since the eager loading pulls from multiple tables, you‘ll have to disambiguate any column references in both conditions and orders. So :order => "posts.id DESC" will work while :order => "id DESC" will not. Because eager loading generates the SELECT statement too, the :select option is ignored.

You can use eager loading on multiple associations from the same table, but you cannot use those associations in orders and conditions as there is currently not any way to disambiguate them. Eager loading will not pull additional attributes on join tables, so "rich associations" with has_and_belongs_to_many are not a good fit for eager loading.

When eager loaded, conditions are interpolated in the context of the model class, not the model instance. Conditions are lazily interpolated before the actual model exists.