I just encountered an interesting scenario that I felt deserved some discussion:

I needed to make a middleware function for getting an ActiveRecord association, and for whatever reason it occurred to me that alias_method_chain was going to be the right way to do it.  While this instinct turned out to be correct, it didn’t occur to me at the time the fact that ActiveRecord sometimes does tricky things involving method_missing and not actually defining its method names.  So when I then had to make a middleware function for getting/setting an ActiveRecord column, I turned to alias_method_chain once more.  Well, when I tried doing that, I received “NameError: undefined method” for the name of the column that I was trying to alias.  What gives?  Why did one of these work and not the other one?

As I mentioned, ActiveRecord overrides the method_missing method to “define” some of its method names during runtime, but although column names are in this list, associations are not.  Therefore, when you define “belongs_to” or “has_many” in your model, it is creating multiple methods at build time to assist you, named with the specific name you passed it.  Column names, however, are not technically defined in the model or anywhere else in code, but by simply what the database returns when asked for these records.  So when you call the name of a column as a method on an ActiveRecord object, it first recognizes that no such method exists, and it then redirects the request to see if any column can be fetched (or has been fetched) from the database with this name.  (Note that this means you can finagle Rails into recognizing anything you select as a “column”, such as aggregations or other calculated values.)  Alias_method and Alias_method_chain require that the method you are trying to alias exists in the first place, so this simply will not work for this case.

If you really think about it, however… Why try to alias something that doesn’t exist in the first place?  Obviously, you can simply write the method yourself and bypass all of the method_missing magic, as long as you know what to reproduce.  The below is how you would reproduce the accessors for the attribute “name” (with no actual changes functionally):

def name
  read_attribute(:name)
end 

def name=(value)
  write_attribute(:name, value)
end

From there, it should be easy to see how to make the changes you want.

-CT

I just found this out myself; I have no idea why this was kept secret from me for so long.  If you need an interface for linking multiple pre-existing model_ones to each of your model_twos, your first thought might be accepts_nested_attributes_for.  While that is a great and versatile tool, it is definitely not easy for every situation, of which I think this is one.  You would probably get stuck trying to figure out the best way to remove old links, recognize existing ones, and add new ones, all in as simple an interface as possible for the user.  For instance, wouldn’t this multi-select box be nice?

AndroidDreamcastiOSPCPlaystation 3WiiXbox 360

That was what I wanted.  What I found out (again?) was that you could do exactly that by writing simply:

<%= f.select :platform_ids, Platform.all.map{|p| [p.name, p.id]}, {}, :multiple => true %>

(Assuming that Game has_many :platforms, :through => :platform_relationships. Remember to put :platform_ids in your attr_accessible!)

So there you are.  Rails really is magic.  It seems that any has_many association recognizes an array of ids as a valid way to list and alter its child relationships in bulk, though the benefit for :through associations is much more meaningful.  The syntax is the collection’s name in singular + “_ids”, and the documentation claims the following:

collection_singular_ids=ids
Replace the collection with the objects identified by the primary keys in ids. This method loads the models and calls collection=.

A few notes:

• Any children orphaned by this operation which are defined as :dependent => :destroy will be destroyed!  This is probably helpful clean-up, but definitely be aware of it.
• For a :through association, the join model will be deleted, not destroyed (no destroy callbacks), and this appears to be independent of :dependent => :destroy.  This may not have adverse effects in most situations, and in fact is probably a good thing as the relationship model is automatically groomed for you.
• If any of the child assignments doesn’t pass validation, the whole operation will fail.
• The assignment operation cannot go through multiple join models, though you can get the current array of ids.  This makes sense in the end, because the second or third join models are probably not simple join models for which we have all the information necessary to create from scratch.

Enjoy!
-Comatose