What's the deal with Rails' polymorphic associations?

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:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

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:

1
2
3
4
5
6

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.

1
2
3
4
5

public interface Collection {

    Collection <<(Object anObject);

}

And the classes.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

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 dont 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.

1
2
3
4
5
6
7
8

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.

1
2
3
4
5
6
7
8

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.

1
2
3
4
5

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 inhierarchy 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 heirarchy 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 heirarchy 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?

1
2
3
4
5
6
7

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 heirarchy 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 heirarchy, 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 module@s 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 didnt know tagging was coming. That’s another agile story.

Anyway, let’s try using modules.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

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 @Address@es and @Company@ies are both addressable and taggable.

1
2
3
4
5

module Addressable

  has_one :address

end

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

1
2
3
4
5
6
7
8
9

module Addressable

  def self.included(klazz)  # klazz is that class object that @include@d 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 heirarchies using STI plus Ruby’s lack of interface@s 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:

1
2
3
4
5
6
7
8
9
10
11
12
13

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.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

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# @interface@s 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.