In diesem Beitrag zeige ich dir das Recordable Pattern, das 37signals (Basecamp, HEY) einsetzt, und erkläre es Schritt für Schritt anhand von lauffähigen Rails-Code-Beispielen. Zielgruppe sind Anfänger bis Fortgeschrittene Ruby on Rails Entwickler, die polymorphe Datenmodelle sauber, skalierbar und gut paginierbar bauen möchten.
Warum das Ganze? Klassische Ansätze wie Single Table Inheritance (STI) oder „nackte“ polymorphe Assoziationen stoßen schnell an Grenzen: STI bläht Tabellen auf, polymorphes CRUD bleibt oft mühsam zu paginieren. Das Recordable Pattern nutzt Rails’ Delegated Types, um eine dünne, performante „Superklasse“-Tabelle (Recording) mit schlanken „Subklasse“-Tabellen (Recordables wie Message, Document, Comment) zu kombinieren.
Das Grundprinzip
- Eine zentrale Tabelle „recordings“ hält alle gemeinsamen Metadaten (z. B. Bucket, Creator, Timestamps) und verweist polymorph auf den „konkreten Inhalt“ (recordable).
- Jede konkrete Recordable (Message, Document, Comment) hat eine eigene Tabelle mit genau ihren Feldern.
- Abfragen, Pagination und gemeinsame Logik passieren über Recording; konkretes Verhalten (z. B.
export_html) lebt bei den Recordables.
So bleibst du:
- flexibel (neue Typen ohne Recording-Migration),
- performant (einheitliche Timeline auf der dünnen Recording-Tabelle),
- sauber getrennt (Metadaten vs. Inhalte).
Minimales Datenmodell
Migration (gekürzt auf das Wesentliche):
create_table :recordings do |t|
t.references :bucket, null: false, foreign_key: true
t.references :creator, null: false, foreign_key: { to_table: :users }
t.string :recordable_type, null: false
t.bigint :recordable_id, null: false
t.index [:recordable_type, :recordable_id]
t.bigint :parent_id # optional: Recording-Baum (Unterelemente)
t.index :parent_id
t.timestamps
end
add_foreign_key :recordings, :recordings, column: :parent_id
create_table :messages do |t|
t.string :title, null: false
t.text :content, null: false
t.timestamps
end
create_table :documents do |t|
t.string :title, null: false
t.text :body
t.string :external_url
t.timestamps
end
create_table :comments do |t|
t.text :body, null: false
t.timestamps
endModels und Concerns
Recording: die „Superklasse“ mit Delegation
class Recording < ApplicationRecord
belongs_to :bucket
belongs_to :creator, class_name: "User"
delegated_type :recordable, types: %w[Message Document Comment], dependent: :destroy
# optional: Baumstruktur
belongs_to :parent, class_name: "Recording", optional: true
has_many :children, class_name: "Recording", foreign_key: :parent_id, dependent: :nullify
# Bequeme Filter-Scopes kommen mit delegated_type:
# Recording.messages, Recording.documents, Recording.comments
endRecordable-Concern: gemeinsame API für Inhalte
module Recordable
extend ActiveSupport::Concern
included do
has_many :recordings, as: :recordable, inverse_of: :recordable
end
def display_title
respond_to?(:title) ? title : self.class.name
end
def export_html
"#{display_title}"
end
endKonkrete Typen:
class Message < ApplicationRecord
include Recordable
validates :title, :content, presence: true
def export_html
"#{title}#{content}"
end
end
class Document < ApplicationRecord
include Recordable
validates :title, presence: true
def export_html
if external_url.present?
"#{title}External: #{external_url}"
else
"#{title}#{body}"
end
end
end
class Comment < ApplicationRecord
include Recordable
validates :body, presence: true
def display_title
body.truncate(40)
end
def export_html
"#{body}"
end
endErstellen und Paginieren einer Timeline
Bucket kapselt die Aufnahme neuer Inhalte („record“) und die Timeline. Bucket ist hier eher abstrakt und könnte genausogut auch ein Projekt sein, oder ein Kunde:
class Bucket < ApplicationRecord
has_many :recordings, dependent: :destroy
def timeline(limit: 50)
recordings.order(created_at: :desc).limit(limit).includes(:recordable)
end
def record(recordable, creator:, parent: nil, color: nil)
recordings.create!(recordable: recordable, creator: creator, parent: parent, color: color)
end
endTypische Abfragen:
bucket = Bucket.find(1)
# Gesamte Timeline effizient paginieren
bucket.timeline(limit: 50).each do |rec|
puts "[#{rec.recordable_type}] #{rec.recordable.display_title}"
end
# Nur bestimmte Typen (Scopes via delegated_type)
Recording.messages.where(bucket: bucket).limit(20)
Recording.documents.where(bucket: bucket).order(created_at: :desc)Versionierung per Repointing (immutable Recordables)
Statt Inhalte zu „updaten“, erzeugst du neue Recordables und verweist die Recording-Zeile auf die neue Version. Das hält Historie sauber und macht Kopieren effizient.
class Recording < ApplicationRecord
# ...
def repoint_to!(new_recordable)
update!(recordable: new_recordable)
end
end
# Beispiel: Message ? neue Document-Version
msg_rec = bucket.record(Message.create!(title: "Kickoff", content: "Welcome!"), creator: user)
new_doc = Document.create!(title: "Specs v2", body: "Updated requirements")
msg_rec.repoint_to!(new_doc) # Recording zeigt nun auf DocumentWenn du eine echte Ereignis-Historie brauchst, ergänze ein Event-Model und schreibe beim record/repoint_to! Einträge (z. B. „created“, „repointed“, inkl. vorher/nachher recordable_type/_id). Das hält Audit-Trails und erlaubt Timeline-Features (siehe Video/37signals-Artikel).
Copy & Move: Subtrees kopieren
Ein Vorteil des Patterns: Kopieren und Verschieben ganzer Teilbäume wird planbar und schnell, weil Recordings leichtgewichtig sind und Recordables immutable dupliziert werden. Eine einfache Kopier-Serviceklasse:
class Copier
def self.copy!(source_recording:, destination_bucket:, creator:)
new(source_recording, destination_bucket, creator).copy!
end
def initialize(source_recording, destination_bucket, creator)
@source_recording = source_recording
@destination_bucket = destination_bucket
@creator = creator
end
def copy!
ActiveRecord::Base.transaction do
copied_root = copy_recording(@source_recording, parent: nil)
@source_recording.children.each { |child| copy_branch(child, parent: copied_root) }
copied_root
end
end
private
def copy_branch(node, parent:)
copied = copy_recording(node, parent: parent)
node.children.each { |child| copy_branch(child, parent: copied) }
copied
end
def copy_recording(original, parent:)
new_recordable = duplicate_recordable(original.recordable)
@destination_bucket.record(new_recordable, creator: @creator, parent: parent, color: original.color)
end
def duplicate_recordable(recordable)
case recordable
when Message
Message.create!(title: recordable.title, content: recordable.content)
when Document
Document.create!(title: recordable.title, body: recordable.body, external_url: recordable.external_url)
when Comment
Comment.create!(body: recordable.body)
else
raise ArgumentError, "Unsupported recordable: #{recordable.class.name}"
end
end
endVergleich mit STI und „plain“ Polymorphismus
- STI: Einfache Fälle ok. Bei divergenten Typen entsteht Tabellen-Bloat, viele NULL-Spalten, Migrationen werden groß, Erweiterbarkeit leidet.
- Polymorphismus ohne
delegated_type: Funktioniert, aber es fehlen bequeme Scopes/Convenience-Methoden; unified Pagination ist oft hakelig. - Recordables +
delegated_type: Einheitliche Timeline über eine dünne Tabelle, klare Trennung von Meta vs. Inhalt, leichte Erweiterbarkeit (neuen Typ hinzufügen statt zentrale Tabelle migrieren), gute Performance bei Abfragen.
Wann solltest du das Pattern nutzen?
- Du brauchst eine gemischte, paginierbare Timeline (z. B. Aktivitätsfeed über Messages, Documents, Comments).
- Deine Typen unterscheiden sich stark in ihren Attributen.
- Du willst Polymorphismus am Parent (Recording) und saubere Delegation an die Inhalte.
Wann eher nicht?
- Deine Subtypen sind fast identisch (STI könnte reichen).
- Du hast keine gemeinsamen Abfragen über Typgrenzen hinweg.
Best Practices
- Halte Recording schlank: nur Metadaten und die polymorphe Referenz. Keine großen Textfelder.
- Packe typenübergreifende Logik in Recording (oder Concerns), typenspezifische Logik in die Recordables.
- Nutze
delegateam Recording für gemeinsame Schnittstellen, z. B.delegate :export_html, to: :recordable. - Wenn Auditing/History wichtig ist, ergänze Events und schreibe Änderungen mit.
- Autorisierung: Recording bündelt viele Aktionen – prüfe Berechtigungen konsequent.
Fazit
Das Recordable Pattern mit delegated_type ist eine elegante, praxiserprobte Lösung für polymorphe Inhalte in Rails. Es bringt dir:
- eine einheitliche, performante Timeline,
- klare Verantwortlichkeiten zwischen Metadaten und Inhaltsobjekten,
- einfache Erweiterbarkeit ohne große Migrationen,
- saubere APIs durch Delegation.
Wenn du Feed-ähnliche Strukturen, Versionierung und Kopier-Features brauchst, wirst du mit Recordings/Recordables sehr schnell produktiv.
Viel Spaß beim Ausprobieren – und schreib mir gern, wenn du Fragen hast oder Beispiele aus deinem Projekt teilen willst!
— Mathias (webmatze.de)
