Types of Associations

 

2 The Types of Associations

Rails supports six types of associations:

• belongs_to
• has_one
• has_many
• has_many :through
• has_one :through
• has_and_belongs_to_many

Associations are implemented using macro-style calls, so that you can declaratively add features to your models. For example, by declaring that one model belongs_to another, you instruct Rails to maintain Primary Key-Foreign Key information between instances of the two models, and you also get a number of utility methods added to your model.

In the remainder of this guide, you'll learn how to declare and use the various forms of associations. But first, a quick introduction to the situations where each association type is appropriate.

2.1 The belongs_to Association

A belongs_to association sets up a one-to-one connection with another model, such that each instance of the declaring model "belongs to" one instance of the other model. For example, if your application includes authors and books, and each book can be assigned to exactly one author, you'd declare the book model this way:

class Book < ApplicationRecord   belongs_to :author end

belongs_to associations must use the singular term. If you used the pluralized form in the above example for the author association in the Book model and tried to create the instance by Book.create(authors: @author), you would be told that there was an "uninitialized constant Book::Authors". This is because Rails automatically infers the class name from the association name. If the association name is wrongly pluralized, then the inferred class will be wrongly pluralized too.

The corresponding migration might look like this:

class CreateBooks < ActiveRecord::Migration[5.0]   def change     create_table :authors do |t|       t.string :name       t.timestamps     end       create_table :books do |t|       t.belongs_to :author       t.datetime :published_at       t.timestamps     end   end end

2.2 The has_one Association

A has_one association also sets up a one-to-one connection with another model, but with somewhat different semantics (and consequences). This association indicates that each instance of a model contains or possesses one instance of another model. For example, if each supplier in your application has only one account, you'd declare the supplier model like this:

class Supplier < ApplicationRecord   has_one :account end

The corresponding migration might look like this:

class CreateSuppliers < ActiveRecord::Migration[5.0]   def change     create_table :suppliers do |t|       t.string :name       t.timestamps     end       create_table :accounts do |t|       t.belongs_to :supplier       t.string :account_number       t.timestamps     end   end end

Depending on the use case, you might also need to create a unique index and/or a foreign key constraint on the supplier column for the accounts table. In this case, the column definition might look like this:

create_table :accounts do |t|   t.belongs_to :supplier, index: { unique: true }, foreign_key: true   # ... end

2.3 The has_many Association

A has_many association indicates a one-to-many connection with another model. You'll often find this association on the "other side" of a belongs_to association. This association indicates that each instance of the model has zero or more instances of another model. For example, in an application containing authors and books, the author model could be declared like this:

class Author < ApplicationRecord   has_many :books end

The name of the other model is pluralized when declaring a has_many association.

The corresponding migration might look like this:

class CreateAuthors < ActiveRecord::Migration[5.0]   def change     create_table :authors do |t|       t.string :name       t.timestamps     end       create_table :books do |t|       t.belongs_to :author       t.datetime :published_at       t.timestamps     end   end end

2.4 The has_many :through Association

A has_many :through association is often used to set up a many-to-many connection with another model. This association indicates that the declaring model can be matched with zero or more instances of another model by proceeding through a third model. For example, consider a medical practice where patients make appointments to see physicians. The relevant association declarations could look like this:

class Physician < ApplicationRecord   has_many :appointments   has_many :patients, through: :appointments end   class Appointment < ApplicationRecord   belongs_to :physician   belongs_to :patient end   class Patient < ApplicationRecord   has_many :appointments   has_many :physicians, through: :appointments end

The corresponding migration might look like this:

class CreateAppointments < ActiveRecord::Migration[5.0]   def change     create_table :physicians do |t|       t.string :name       t.timestamps     end       create_table :patients do |t|       t.string :name       t.timestamps     end       create_table :appointments do |t|       t.belongs_to :physician       t.belongs_to :patient       t.datetime :appointment_date       t.timestamps     end   end end

The collection of join models can be managed via the has_many association methods. For example, if you assign:

physician.patients = patients

Then new join models are automatically created for the newly associated objects. If some that existed previously are now missing, then their join rows are automatically deleted.

Automatic deletion of join models is direct, no destroy callbacks are triggered.

The has_many :through association is also useful for setting up "shortcuts" through nested has_many associations. For example, if a document has many sections, and a section has many paragraphs, you may sometimes want to get a simple collection of all paragraphs in the document. You could set that up this way:

class Document < ApplicationRecord   has_many :sections   has_many :paragraphs, through: :sections end   class Section < ApplicationRecord   belongs_to :document   has_many :paragraphs end   class Paragraph < ApplicationRecord   belongs_to :section end

With through: :sections specified, Rails will now understand:

@document.paragraphs

2.5 The has_one :through Association

A has_one :through association sets up a one-to-one connection with another model. This association indicates that the declaring model can be matched with one instance of another model by proceeding through a third model. For example, if each supplier has one account, and each account is associated with one account history, then the supplier model could look like this:

class Supplier < ApplicationRecord   has_one :account   has_one :account_history, through: :account end   class Account < ApplicationRecord   belongs_to :supplier   has_one :account_history end   class AccountHistory < ApplicationRecord   belongs_to :account end

The corresponding migration might look like this:

class CreateAccountHistories < ActiveRecord::Migration[5.0]   def change     create_table :suppliers do |t|       t.string :name       t.timestamps     end       create_table :accounts do |t|       t.belongs_to :supplier       t.string :account_number       t.timestamps     end       create_table :account_histories do |t|       t.belongs_to :account       t.integer :credit_rating       t.timestamps     end   end end

2.6 The has_and_belongs_to_many Association

A has_and_belongs_to_many association creates a direct many-to-many connection with another model, with no intervening model. For example, if your application includes assemblies and parts, with each assembly having many parts and each part appearing in many assemblies, you could declare the models this way:

class Assembly < ApplicationRecord   has_and_belongs_to_many :parts end   class Part < ApplicationRecord   has_and_belongs_to_many :assemblies end

The corresponding migration might look like this:

class CreateAssembliesAndParts < ActiveRecord::Migration[5.0]   def change     create_table :assemblies do |t|       t.string :name       t.timestamps     end       create_table :parts do |t|       t.string :part_number       t.timestamps     end       create_table :assemblies_parts, id: false do |t|       t.belongs_to :assembly       t.belongs_to :part     end   end end

2.7 Choosing Between belongs_to and has_one

If you want to set up a one-to-one relationship between two models, you'll need to add belongs_to to one, and has_one to the other. How do you know which is which?

The distinction is in where you place the foreign key (it goes on the table for the class declaring the belongs_to association), but you should give some thought to the actual meaning of the data as well. The has_one relationship says that one of something is yours - that is, that something points back to you. For example, it makes more sense to say that a supplier owns an account than that an account owns a supplier. This suggests that the correct relationships are like this:

class Supplier < ApplicationRecord   has_one :account end   class Account < ApplicationRecord   belongs_to :supplier end

The corresponding migration might look like this:

class CreateSuppliers < ActiveRecord::Migration[5.2]   def change     create_table :suppliers do |t|       t.string :name       t.timestamps     end       create_table :accounts do |t|       t.bigint  :supplier_id       t.string  :account_number       t.timestamps     end       add_index :accounts, :supplier_id   end end

Using t.bigint :supplier_id makes the foreign key naming obvious and explicit. In current versions of Rails, you can abstract away this implementation detail by using t.references :supplier instead.

2.8 Choosing Between has_many :through and has_and_belongs_to_many

Rails offers two different ways to declare a many-to-many relationship between models. The simpler way is to use has_and_belongs_to_many, which allows you to make the association directly:

class Assembly < ApplicationRecord   has_and_belongs_to_many :parts end   class Part < ApplicationRecord   has_and_belongs_to_many :assemblies end

The second way to declare a many-to-many relationship is to use has_many :through. This makes the association indirectly, through a join model:

class Assembly < ApplicationRecord   has_many :manifests   has_many :parts, through: :manifests end   class Manifest < ApplicationRecord   belongs_to :assembly   belongs_to :part end   class Part < ApplicationRecord   has_many :manifests   has_many :assemblies, through: :manifests end

The simplest rule of thumb is that you should set up a has_many :through relationship if you need to work with the relationship model as an independent entity. If you don't need to do anything with the relationship model, it may be simpler to set up a has_and_belongs_to_many relationship (though you'll need to remember to create the joining table in the database).

You should use has_many :through if you need validations, callbacks, or extra attributes on the join model.

2.9 Polymorphic Associations

A slightly more advanced twist on associations is the polymorphic association. With polymorphic associations, a model can belong to more than one other model, on a single association. For example, you might have a picture model that belongs to either an employee model or a product model. Here's how this could be declared:

class Picture < ApplicationRecord   belongs_to :imageable, polymorphic: true end   class Employee < ApplicationRecord   has_many :pictures, as: :imageable end   class Product < ApplicationRecord   has_many :pictures, as: :imageable end

You can think of a polymorphic belongs_to declaration as setting up an interface that any other model can use. From an instance of the Employee model, you can retrieve a collection of pictures: @employee.pictures.

Similarly, you can retrieve @product.pictures.

If you have an instance of the Picture model, you can get to its parent via @picture.imageable. To make this work, you need to declare both a foreign key column and a type column in the model that declares the polymorphic interface:

class CreatePictures < ActiveRecord::Migration[5.2]   def change     create_table :pictures do |t|       t.string  :name       t.bigint  :imageable_id       t.string  :imageable_type       t.timestamps     end       add_index :pictures, [:imageable_type, :imageable_id]   end end

This migration can be simplified by using the t.references form:

class CreatePictures < ActiveRecord::Migration[5.0]   def change     create_table :pictures do |t|       t.string :name       t.references :imageable, polymorphic: true       t.timestamps     end   end end

2.10 Self Joins

In designing a data model, you will sometimes find a model that should have a relation to itself. For example, you may want to store all employees in a single database model, but be able to trace relationships such as between manager and subordinates. This situation can be modeled with self-joining associations:

class Employee < ApplicationRecord   has_many :subordinates, class_name: "Employee",                           foreign_key: "manager_id"     belongs_to :manager, class_name: "Employee", optional: true end

With this setup, you can retrieve @employee.subordinates and @employee.manager.

In your migrations/schema, you will add a references column to the model itself.

class CreateEmployees < ActiveRecord::Migration[5.0]   def change     create_table :employees do |t|       t.references :manager       t.timestamps     end   end end