The Buckblog

Thanks for the tip! I was always using your last example (adding a class method), but extending the associating is indeed a better thing to do. It allows better method chaining.

Hey this is an interesting insight. I’m new to ROR and programming and I was just wondering what is “memoize” and “memoize the results”? If you could explain it in non-computer term if that makes sense : )

I get the sense your saving time and possibly creating speed on querying by using the “memoize” approach. It seems like something you would want to do when your “refactoring” your code I’m guessing ?

How about reorganizing “memoized_finder” (maybe call it just “memoize”) to follow the pattern used in the “memoize” gem, where original methods are left untouched and memoization is applied declaratively, one line, very clean. Setting instance variables (@active and @inactive) not even needed.

class Project < ActiveRecord::Base has_many :tasks, :dependent => :delete_all do def active find(:all, :conditions => “status = ‘active’”) end end

def inactive
    find(:all, :conditions => "status = 'inactive'")
  end
end

memoize :active, :inactive

A newbie question – in which file must be saved the declaration of the memoized_finder method?

Thanks for this awesome article that goes deeper into the problem the guys at therailsway.com show us with ” AssetsGraphed: Part 1”.

Very clean and ninja solution ! Sandro

Sandro, Jamis is, together with Koz, the therailsway.com editor, actually, the “AssetsGraphed: Part 1” was written by Jamis himself :-)

Jamis, congratulations for another great article. Before reading your arguments to push the active/inactive code into Project instead of Task, I would swear that the best way was to have it under Task to keep the classes more atomic and decoupled. You managed to change my mind on the last paragraph. Oh, the memoized_finder trick was very nice, by the way.

Jamis- Is there a way to use the currently instantiated objects id in the conditions? Say I want:

has_many :foos do memoized_finder :contributed, ‘user_id = #{id}’ end

I’m currently doing this through nested/inherited has_many through. Like:

has_many :foos, :conditions => “deleted_at IS NULL” has_many :contributed_foos, :through => :foos, :conditions => ‘user_id = #{id}’

By using ’’ instead of ”” on the conditions it replaces id on the first call, not at compile time.

I probably shouldn’t even be posting this until I’ve had coffee…

Jamis- I’ll assume you’re not a South Park fan. You can refer to me as the post above if it’s less painful. ;)

has_many :foos do
  memoized_finder :contributed "user_id = \#{id}" 
end

generates the following, maybe I’m missing something?

...AND (foos.user_id = #{id}))

It looks like using double quotes in a has_many :conditions it evaluates at compile time and using single quotes it evaluates per instance.

This one works as it substitutes the #{id} for the current user. It’s not as pretty as yours, but it does have the same effect of caching the results.

has_many :foos, :order => 'position',
  :conditions => "deleted_at IS NULL" 

has_many :contributed_foos, :source => 'foo', 
  :through => :foos,
  :order => 'position',
  :conditions => 'foos.user_id = #{id}'

Jamis, I like to keep the extensions in an Extensions module inside of the association’s class.

class Task … ... end

module Extensions
  def active
   ...
  end 
end

And then do:

has_many :tasks, :extend => Task::Extensions

To me it seems cleaner to keep the logic about what the different states of a task are inside the task.rb file. It also makes it easier to reuse between other objects.

I’ve got an ongoing struggle though since it seems like I should be able to combine association extensions and scopes so that I could get the sexy AssociationCollection smart-queries. I long to do:

@project.tasks.active.size (and have it do COUNT), likewise @project.tasks.active.empty?

Thanks for the great article.

Jamis, you’re right, using the :extend to a sub-module is a bit indirect and I don’t do it for one or two methods either.

Could you comment on my idea of an AssociationCollection/extensions/scopes mashup? Since scopes are how the association extensions work it seems like you should be able to define additional scopes and then let the parent association collection do its magic.

Jamis – thanks for the great article. I read your other article at the Rails Way on this subject and I wasn’t entirely convinced that doing these custom associations was any better than using class-based finders and letting the association scope it for you. After reading this article tho, I can see the huge benefit now (like, smacking me in the face) that it could save some hits to the database. Now I realize that the class finders aren’t going to give you any kind of caching via association (e.g. if you define

Task.find_active

some_project.tasks

some_project.tasks.find_active

Joshua, the only thing I can think of to get the magic you’re looking for would be to explicitly define memoized versions of those functions, like:

Or maybe you don’t want it to be memoized, for something like count. I think I would have a concern where I might have

some_project.tasks.active

some_project.tasks.active_count

some_project.tasks.active.size

sorry about the formatting there – I transposed my ‘pre’ and ‘code’ tags…

I totally love this extension concept! I’ve been doing stuff like:

@job.tasks.all?(&:finished?)

But

@job.tasks.all_finished?

is so much nicer! Where is this documented? I couldn’t find any reference to it in the API.

Thanks!

First of all, thanks for pointing this out! I just found this blog a week or so ago, and I’ve already learned a bunch of great tips! Really excellent!

Now I’m going to ask for help ;)

I was wondering if there is any way to do something like this with the following. Right now I have:

class Person < ActiveRecord::Base
    has_many :received_gifts, :foreign_key => 'receiver_id', :class_name => 'Gift'
    has_many :given_gifts, :foreign_key => 'giver_id', :class_name => 'Gift'
end

class Gift < ActiveRecord::Base
    belongs_to :giver, :foreign_key => 'giver_id', :class_name => "Person" 
    belongs_to :receiver, :foreign_key => 'receiver_id', :class_name => "Person" 
end

Can I somehow combine those has_many associations so that I can get @person.gifts.received and @person.gifts.given?

Okay, thanks, Jamis. I guess that’s what I’ll have to do for now. Thanks for the help!

This is fantastic, thanks.

Jamis, another question for you: How would one go about making these association extensions available for a collection of objects that aren’t related to their parent? To use continue with your example, what if I’ve got some subset of tasks? I’d love to be able to call “tasks.active” no matter where those tasks came from. Any ideas?

Thanks!

Jamis, I understand that part. I’ve refactored a bunch of code already, thanks to this tip. But is there any way to achieve the same functionality that these extensions give for collections in the context of the parent (e.g project.tasks.active) on a “bare” collection?

What if I end up with a bunch of Tasks that are seperate from a single Project? I’d like to be able to apply active() to them also (random_tasks.active), but can’t in this case because they are not attached to a Project with the extension.

I’d really like to just extend Array with a variation of active(), but only have it apply to arrays of Task objects. It’s not a major issue, but it would be nice to maintain consistency with the project.tasks.active style. That make more sense?

Interesting. Thanks for doing a post on extending and working with these associations. It seems like they don’t get as much attentions as other ActiveRecord features, like find() and the relationship methods, but they’re every bit as important.

Jamis, I enjoy that you’re explaining these ideas because I believe people should learn to love association extensions (seriously… everyone should use them), but I have one question:

find

class Project < ActiveRecord::Base
  has_many :tasks, :dependent => :delete_all do
    def active(reload = false)
      @active = nil if reload
      @active ||= self.select { |task| task.status == "active" }
    end
    ...
  end
end

That way, if you haven’t pre-loaded your association, Rails will automatically fetch the contents, but if you’ve eager loaded the association, it will use that instead without the extra query.

I used to do

find

If I’m missing something, however, please let me know!

Dear Jamis,

You are a serious hoss. Keep it coming.

Sincerely, Adam Keys