We hold a Ruby Campfire at the company I work for, bi-weekly. It's not a real campfire of course — we work remotely! Recently, we talked about Ruby delegated types in one of those meetings. It was really interesting. I used to use STI (Single Table Inheritance) to connect multiple tables, but it turns out there is a different and more effective solution.
Background
Single-table inheritance looks simple at first. One table, one type column, done. Rails makes it easy to set up.
But then the problems start.
I've been writing Rails apps for over 14 years. I've seen the STI trap many times in my own code too. You start with two or three similar models, put them in one table, and move on. Six months later, the table has thirty columns. Most of them are NULL for any given row. The type column is the only thing keeping it together.
There's a better option. Rails has had it since 6.1. It's called delegated types.
What's Wrong With STI
STI works fine when your models are very similar. When they share most columns and only differ a little in behavior. The Rails docs say it clearly:
"STI works best when there's little divergence between the subclasses and their attributes."
A simple example: you have Message and Comment. You want to show both in a feed and paginate them together. STI lets you do that. But a Message has a subject column. A Comment doesn't. With STI, the comment row gets a subject column anyway. It's just always NULL.
Do this with enough models and enough columns, and your table becomes a mess. It's hard to query, hard to index, and hard to understand.
Polymorphic associations fix the sparse table problem, but they bring other issues: no foreign key constraints, more complex queries, and it gets confusing fast.
A Third Option
DHH added delegated types to Rails 6.1. The idea is simple: keep the shared columns in one "superclass" table. Give each subclass its own table for the columns that are specific to it.
DHH said this pattern had "the most profound impact on how we do domain modeling at Basecamp". They used it in Basecamp 3 and then in HEY.
Here's how it looks. You have an Entry model. It holds the shared stuff: creator_id, account_id, timestamps. Then Message and Comment each have their own tables with their own specific columns.
class Entry < ApplicationRecord
delegated_type :entryable, types: %w[ Message Comment ]
delegate :title, to: :entryable
end
class Message < ApplicationRecord
def title
subject
end
end
class Comment < ApplicationRecord
def title
content.truncate(20)
end
end
Now you can call entry.title on anything in the feed. Message returns its subject. Comment returns a short preview. The caller doesn't need to care which one it is.
The schema stays clean. The entries table has only shared columns. The messages and comments tables have only their own columns. No NULL columns, no if record.type == "Message" checks in your views.
How Is This Different From Polymorphic Associations?
Delegated types are built on top of polymorphic associations. DHH called it "syntactic sugar" in some early discussions. But the intent is different.
With normal polymorphic associations, you go from parent to child: fetch a Post, then get its images. With delegated types, you go the other way. You query from Entry and let it delegate to the specific type. Entry is the main entry point. Message and Comment are details.
This means you can write Entry.all and paginate across all types with no UNION queries. You can eager-load associations on Entry. You can build controllers around Entry that work for both messages and comments.
When to Use It
Delegated types aren't always the right choice. If your models are very similar and you don't need pagination across types, STI is fine.
But if you see yourself doing any of these things, delegated types are worth trying:
- Adding columns to an STI table that only one model uses
- Writing
if record.type == "Message"in views or controllers - Having trouble paginating across different model types
- Building a feed, timeline, or activity log with different kinds of content
One Thing to Know
When you need to filter by a subtype-specific column, you need a join. If you want to filter by messages.subject, you join entries to messages. This is usually fine, but it's good to know before you start.
How to Set It Up
Creating a record is simple:
Entry.create!(
entryable: Comment.new(content: "Hello!"),
creator: Current.user,
account: Current.account
)
Rails gives you scopes and helpers automatically: Entry.messages, Entry.comments, entry.message?, entry.comment?. Rendering is clean too:
<%# entries/_entry.html.erb %>
<%= render "entries/entryables/#{entry.entryable_name}", entry: entry %>
Each type gets its own partial. Entry doesn't need to know which one to pick.
Why It Matters
Rails is opinionated. It bets that good conventions make code easier to work with over time. Delegated types feel like one of those conventions — not a new abstraction for its own sake, but a name and a structure for something developers were already doing by hand, usually in a messier way.
If you've been using STI out of habit, it's worth reconsidering. Not every model hierarchy needs delegated types. But the ones that do will be much cleaner for it.
I write about Ruby, Rails, and software development every Thursday. You can follow me at enderahmetyurt.com.
