Fun with Single Table Inheritance
published Dec 31, 2007
I’m working on the sample application for the Intermediate Ruby on Rails Workshop that Gerald Bauer and I are putting on in January. I had to remind myself of some of the foibles of Single Table Inheritance (STI). I thought others might find this useful, so here’s what I found.
The Set-up
I have two types of posts in the application I’m building: posts by people with an empty room looking for a roomie (RoomiePosts), and posts by people looking for a room (RoomPosts). They both share a lot of the same attributes, so it’s not very DRY to create two separate models.
This is where Single Table Inheritance comes in. STI is basically a way of subclassing a single model, creating subclasses that all use the same database table.
What I did is create a Post model and two subclasses: RoomiePost and RoomPost. Here’s how you do it.
Creating the Database Table
Here’s the migration for the posts database table. Note that this uses the new migrations syntax in Rails 2.0.
Most of the columns are pretty straightforward. text
will contain the text of the post. start_date
and expiry_date
will determine when the post will start and stop being shown on the site. rent
and includes_utilities
will only be used by the RoomiePost subclass, but still need to be created for all subclasses of the Post model.
The interesting column is type
. This allows Rails to determine which subclass the row should be loaded in to. If you set type = "RoomiePost"
, then it’s a RoomiePost. If you set type = "RoomPost"
, then it’s a RoomPost.
Creating the Models
You need to create a Post, RoomiePost and RoomPost model. They look like this:
In /app/models/post.rb
In /app/models/roomie_post.rb
In /app/models/room_post.rb
Note that RoomiePost and RoomPost are both subclasses of the Post model. Here’s where you run in to a “gotcha”.
You have to create the models in separate files. If you don’t, Rails ignores the subclassed models.
For more information, and another workaround, see this blog post. The comment by Chris at the bottom gives the ‘create the models in separate files’ solution.
Okay, so now you have the models all set up. You can do things like
And it will create a row in the posts
table with type = "RoomiePost"
. If you have 5 RoomiePosts and 2 RoomPosts, then Posts.count will return 7.
Adding behaviour to STI models
I want to be able to determine if a post is active by looking at the start and expiry dates, and to get a list of all active posts, roomie_posts and room_posts. I also want to have a different icon for each post type.
The Post.active_post? and Post::active_posts methods are straight-forward:
The only tricky part is that I used self.find(:all)
instead of Post.find(:all)
in the Post::active_posts method. This makes sure that RoomiePost::active_posts only returns RoomiePosts and RoomPost::active_posts only returns RoomPosts.
Getting the icon to work took a little more figuring out. If I wanted to do this in straight-up Ruby, I’d do something like
Then I could do this
This doesn’t quite work in the Rails version. Not to worry, you only have to make one simple change:
replace the initialize
method with an after_initialize
callback.
The final post.rb
, roomie_post.rb
and room_post.rb
files look like this:
post.rb
:
roomie_post.rb
:
room_post.rb
:
One final note: because of the way the after_initialize
callback works, you have to actually define an after_initialize
method. You can’t do something like this:
If you want to learn more about STI, and a whole slew of other info on Rails, sign up for the Intermediate Rails Workshop on January 25th, 2008 in Vancouver.
Early Bird rates are available until January 9th!