What's the Deal with Rails' Polymorphic Associations?

Jared Carroll

The latest big ActiveRecord feature to Rails has been polymorphic associations. Not very clear at first, I found out they’re easier to understand with a couple examples.

A common one:

class Person < ActiveRecord::Base
  has_one :address, :as => :addressable
end

class Company < ActiveRecord::Base
  has_one :address, :as => :addressable
end

class Address < ActiveRecord::Base
  belongs_to :addressable, :polymorphic => true
end

This basically allows the address class to belongs_to any model. Which is nice, the alternative would be to say:

class Address < ActiveRecord::Base
  belongs_to :person
  belongs_to :company
end

Then you’d have all these foreign keys in your addresses table but you only would ever have a value for one of them because an address can only belong to a person or a company but not both.

OK that was the basics.

Now the rails docs refer to the as keyword parameter to has_one and has_many as specifying a “polymorphic interface.” What is that?

When I think"polymorphic interface", I think something along the lines of the << message in Ruby. I can send that message to a bunch of different objects like arrays, strings, IO streams, etc. and they all know what to do when they receive it.

I think << as a kind of interface that all those different classes implement. From a statically typed language standpoint, such as Java, it would be as if we had a nice little hierarchy of classes all implementing a common interface.

Pretending Java allowed operator overloading and << was an operator it might look like this.

public interface Collection {
  Collection <<(Object anObject);
}

And the classes.

public class Array implements Collection {
  public Collection << (Object object) {
    // add object to me
  }
}

public class String implements Collection {
  public Collection << (Object object) {
    // add object to me
  }
}

Where am I going with this? Stay with me here.

Lets rotate the class diagram for the Person, Company, and Address 90 degrees to the left (I don’t know how to draw that here but if you write it out on paper you’ll see what I mean) and make Person and Company inherit from Address.

class Address < ActiveRecord::Base
end

class Person < Address
end

class Company < Address
end

Now neither a Person nor a Company are an Address so lets instead use that “polymorphic interface” as our superclass name.

class Addressable < ActiveRecord::Base
end

class Person < Addressable
end

class Company < Addressable
end

That’s better. A Person and a Company are addressable but what happened to the Address class.

class Addressable < ActiveRecord::Base
  has_one :address
end

There we go. Now Person and Company has_one address, they inherit it from Addressable, and no polymorphic associations.

But wait, inheritance? More specifically in the Rails world, “single-table inheritance” (STI) ? Let’s pretend a Person and a Company have very little state in common; what does using (STI) give us? It’s gives us a giant table with a lot of empty columns for the Company attributes when the row is a Person and a lot of empty columns for the Person attributes when the row is a Company.

I don’t like it.

As more Addressable‘s come into the system that table is going to get bigger and bigger. To me using Addressable makes sense, inheritance is about behavior and not about state and if I was modeling without thinking about a database I probably would of first came up with using the Addressable class.

What can we conclude? We can say that STI is basically a way to map an inheritance hierarchy for a bunch of classes that have a lot of common state not behavior.

Now there are other ways to map an inheritance hierarchy to a relational database. In fact there’s 3 commonly used ones. Rails only gives us the simplest one STI.

  • Single Table Inheritance (STI) - The whole hierarchy is mapped to a single table with an extra column (“type” in Rails) that holds the class name for that row
  • One Table per Concrete Class - Each concrete class gets its own table, the superclass (like all good superclasses) is abstract and does not get its own table. Any common state in the superclasses is duplicated in each subclass table.
  • One Table per Class - Each class in the hierarchy gets its own table. Subclass tables have foreign keys referencing their corresponding superclass row in the superclass table.

For the 2nd one it won’t work. But that last one “One Table per Class” is interesting.

Back to our Person, Company, and Addressable example.

If we mapped each of those classes to its own table what would or database look like?

addressables (id)
people (id, name, age, height, weight, addressable_id)
companies (id, size, established_date, addressable_id)
addresses (id, street, city, state, addressable_id)

Hmmm. We get to use the nice hierarchy that uses behavior to model inheritance with Addressable as our superclass and we don’t have to put all the subclasses into their own table. So we got rid of that big ugly STI table with all those empty columns. When reading a Person from the database, we’d do a join to Person’s superclass table addressables on addressable_id. And to read a Person’s address we’d do a join to addresses on addressable_id.

So we eliminated polymorphic associations and replaced them with inheritance, assuming rails supported our inheritance mapping scheme of “One Table per Class”, which it doesn’t but lets keep going. And I like our hierarchy, a Person is Addressable, a Company is Addressable it reads nice and logical. One beef. What’s the deal with that addressables table? A table with one column. That’s weird. For now, mark it down as a disadvantage and some ugliness with this method.

But wait. Here comes another feature. Users now want to be able tag people and companies. We could use the Rails plugin acts_as_taggable, which uses polymorphic associations. Let’s not and keep running with this to see where it takes us.

A Taggable class sounds good. But wait. Ruby doesn’t allow multiple inheritance and it doesn’t have the Java/C# equivalent of interfaces. Ruby uses modules instead. OK so we screwed up. We should of modeled Addressable as a module and not a class. I say we didn’t screw up - we modeled that because that’s what the current requirements were; we didn’t know tagging was coming. That’s another agile story.

Anyway, let’s try using modules.

module Addressable
end

module Taggable
end

class Person < ActiveRecord::Base
  include Addressable
  include Taggable
end

class Company < ActiveRecord::Base
  include Addressable
  include Taggable
end

There that’s better now Addresses and Companies are both addressable and taggable.

module Addressable
  has_one :address
end

Wait, we can’t do that in Rails. OK how about this.

module Addressable
  def self.included(klazz)  # klazz is that class object that included this module
    klazz.class_eval do
      has_one :address
    end
  end
end

There now, each class that includes the Addressable module has_one Address. Hold up. What would our database look like?

addresses (id, street, city, state, person_id, company_id)

Oh no, we’re back to where we started. An Address can’t belongs_to a Person and a Company at the same time. We need polymorphic associations.

Wow, that was a trip. What did we learn. At first we started out using polymorphic associations. Then we decided to refactor and try modeling in what I’d call “the more natural way” using inheritance and Addressable and Taggable classes. But we eventually got burnt when a Person and a Company both needed to be Taggable as well. So we used Ruby’s version of interfaces/multiple inheritance by using modules. And that got us right back to where we started

The moral of the story is this because Rails only allows you to map inheritance hierarchies using STI plus Ruby’s lack of “interfaces we can’t model using interface like classes like Addressable” and Taggable. Instead we use polymorphic associations and let them use that “polymorphic interface” for the name of the association:

class Address < ActiveRecord::Base
  # here's where we'll use Addressable
  belongs_to :addressable, :polymorphic => true
end

class Tagging < ActiveRecord::Base
  # here's where we'll use Taggable
  belongs_to :taggable, :polymorphic => true
end

I like modeling using interfaces such as Addressable and Taggable. I really like the following Java classes.

public interface Addressable {
  Address getAddress ();

  void setAddress (Address address);
}

public class Address {
  private String street;
  private String city;
  private State state;
  private Zipcode zipcode;
  private Addressable addressable;    // anyone who implements Addressable

  // various getters and setters, etc.
}

public class Person implements Addressable {
  private Address address;

  public Address getAddress () {
    return address;
  }

  public void setAddress (Address address) {
    this.address = address;
  }
}

public class Company implements Addressable {
  private Address address;

  public Address getAddress () {
    return address;
  }

  public void setAddress (Address address) {
    this.address = address;
  }
}

And for Taggable

public interface Taggable {
  Collection getTaggings ();
}

public class Tagging {
  private Taggable taggable;  // anyone who implements Taggable
  private Tag tag;

  // various getters/setters, etc.
}

public class Person implements Addressable, Taggable {
  // Addressable implementation from above
  private Collection taggings;

  public Collection getTaggings () {
    return taggings;
  }
}

public class Company implements Addressable, Taggable {
  // Addressable implementation from above
  private Collection taggings;

  public Collection getTaggings () {
    return taggings;
  }
}

In Object-relational mapping (ORM) libraries in the Java/.Net world they provide all 3 inheritance mapping schemes whereas in Rails you only get STI.

Were the other 2 inheritance mapping schemes too “enterprise” for Rails? Too complicated for DHH to implement? Nah, Ruby’s lack of interfaces make the other 2 schemes not as powerful as in languages that support interfaces e.g. like in the above example Addressable worked fine, but the minute we introduced Taggable i.e. another “interface” we were done for.

And Rails form of “polymorphic associations” aren’t found in Java/.Net object-relational mapping libraries as well. Of course not, Ruby’s use of modules as a form of multiple inheritance required something unique, “polymorphic associations” are that something. Look at the source for the popular acts_as_taggable plugin. It uses polymorphic associations and it uses modules to include in any shared behavior such as instance and classes methods. This is nice. You call acts_as_taggable in your class definition and you get all this behavior for free.

I’m sorry, but I miss my interfaces. Looking at the above Java code, you might say “yeah but look at that Addressable and Taggable implementation in the Person and Company classes its exactly the same, its not DRY. In Ruby with modules you’d only have to implement that once and just include it into the Person and Company classes”. That’s true but if someone decides to change that module it might break classes that include it - that’s another story something called the “brittle base class”. I also like the fact that its explicit, its duplicated but I can see the code in both the Person and Company classes, no messing around in $RAILS_ROOT/vendor/plugins.

Well if you made it through that you’re just as crazy as I am. But I’m scoring this one a point for Java/C#. Ruby usually dominates but being able to use those Java/C# interfaces just seem more natural and better to me. And the fact that Rails’ polymorphic associations are a new thing, there’s definitely a source of confusion around them in the Rails community.

Detect emerging problems in your codebase with Ruby Science. We’ll deliver solutions for fixing them, and demonstrate techniques for building a Ruby on Rails application that will be fun to work on for years to come.

Grab a free sample of Ruby Science today!