This post originated from an RSS feed registered with Ruby Buzz
by Scott Patten.
Original Post: Fun with Single Table Inheritance
Feed Title: Scott Patten's Blog
Feed URL: http://feeds.feedburner.com/scottpatten.ca
Feed Description: Scott Patten is the cofounder of Ruboss (http://ruboss.com) and Leanpub (http://leanpub.com), both based in Vancouver.
He is also the author of The S3 Cookbook (http://leanpub.com/thes3cookbook).
He blogs about Startups, Ruby, Rails, Javascript, CSS, Amazon Web Services and whatever else strikes his fancy.
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
123
classPost < ActiveRecord::Baseend
In /app/models/roomie_post.rb
123
classRoomiePost < Postend
In /app/models/room_post.rb
123
classRoomPost < Postend
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
>> p = RoomiePost.create(:rent => 800, :includes_utilities => true, :text => "Great room in a shared house in the Commercial Drive area")
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.
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
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:
12345678910
classRoomiePost < Post after_initialize :set_icon_name privatedefset_icon_name@icon_name = 'roomie.gif'endend
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.