Single Table Inheritance in Rails

Skip Baney

Handwire

The Setup

• You have a site that has two content types: Post and Event
• Both can be commented upon
• Both have a creator and updater
• Events can be attended

Traditional: Migration I

create_table :posts do |t|
  t.column :title,            :string
  t.column :body,             :text
  t.column :created_by,       :int
  t.column :updated_by,       :int
end

create_table :events do |t|
  t.column :title,            :string
  t.column :body,             :text
  t.column :location,         :text
  t.column :created_by,       :int
  t.column :updated_by,       :int
end

Traditional: Migration II

create_table :post_comments do |t|
  t.column :post_id,       :int
end

create_table :event_comments do |t|
  t.column :event_id,       :int
end

create_table :attendees do |t|
  t.column :event_id,       :int
end

Traditional: Models

class Post < ActiveRecord::Base
  acts_as_taggable
  has_many   :comments, :class_name => 'PostComment'
  belongs_to :creator
  belongs_to :updater
end

class Event < Content
  acts_as_taggable
  has_many   :comments, :class_name => 'EventComment'
  has_many   :attendees
  belongs_to :creator
  belongs_to :updater
end

Code Reuse is Sweet!

• DRY
• Prevent bugs
• Share functionality

ORM and Inheritance

• Three ways to model your inheritance hierarchy from our good friend Martin Fowler

Concrete Table Inheritance

• one table per concrete class - shared properties are duplicated in the tables

  

Class Table Inheritance

• one table for each class - shared properties are stored in the parent class

  

Single Table Inheritance

• single table that has columns for all the fields of the various classes

  

Rails uses STI

• Create one table with columns for all properties
• Add a column named 'type'
• type can have a default value
• type is a reserved column name

Don't like type?

class Blood < ActiveRecord::Base
  has_many :donors

  def inheritance_column
    'class_name'
  end
end

STI:

• Let's refactor Post and Event

SIT: Migration

create_table :contents do |t|
  t.column :type,             :string
  t.column :title,            :string
  t.column :body,             :text
  t.column :location,         :text
  t.column :created_by,       :int
  t.column :updated_by,       :int
end

create_table :comments do |t|
  t.column :content_id,       :int
end

create_table :attendees do |t|
  t.column :content_id,       :int
end

STI: Models

class Content < ActiveRecord::Base
  acts_as_taggable
  has_many   :comments
  belongs_to :creator
  belongs_to :updater
end

class Post < Content
end

class Event < Content
  has_many :attendees
end

Pros

• Easily aggregate different types of data
  • Content.find returns Post and Event objects
  • Event.find only returns Event objects
• Share associations/tables (without needing polymorphic)
• Share validations
• Potentially share controllers...

Cons

• "They seemed to have a lot in common..."
• Unused attributes
• No foreign key constraints on :belongs_to

Best Practice?

• Models that share all/most properties, but you'd like to add custom behavior or be able to easily segregate them based on class
  • taxonomies (ProjectStatus, UserStatus)
  • product types (Widget, SuperWidget, etc...)
• Cases where content aggregation is important, as in a CMS or tumblelog

Alternatives

• Polymorphic associations
  • Negate the use of STI just for shared associations
  • Problems with joining tables (:through, :include)?
• Aggregate tables
  • Use an observer on multiple models with after_save

Thanks!

• Slides online at:
  http://twelvelabs.com/singletable/index.html
  (thanks Eric Meyer)
• Questions?