Railsでは、「関連付け(アソシエーション: association)」とは2つのActive Recordモデル同士のつながりを指します。モデルとモデルの間には関連付けを行なう必要がありますが、その理由を御存じでしょうか。それは、関連付けを行う事であなたのコードでの共通操作をよりシンプルで簡単にするからです。簡単なRailsアプリケーションを例にとって説明しましょう。このアプリケーションには著者用のモデル(Author)と書籍用のモデル(Book)があります。一人の著者は、複数の書籍を持っています。関連付けを設定していない状態では、モデルの宣言は以下のようになります。
class Author < ApplicationRecord end class Book < ApplicationRecord end
ここで、既存の著者が新しい書籍を1つ執筆したくなったとします。この場合、以下のようなコードを実行する必要があるでしょう。
@book = Book.create(published_at: Time.now, author_id: @author.id)
今度は著者を削除する場合を考えてみましょう。著者を削除するなら、以下のように、執筆した書籍も残らず削除されるようにしておかなければなりません。
@books = Book.where(author_id: @author.id) @books.each do |book| book.destroy end @author.destroy
Active Recordの関連付け機能を使うと、2つのモデルの間につながりがあることを明示的にRailsに対して宣言でき、それによってモデルの操作を一貫させることができます。著者と書籍の設定するコードを次のように書き直せます。
class Author < ApplicationRecord has_many :books, dependent: :destroy end class Book < ApplicationRecord belongs_to :author end
上のように関連付けを追加したことで、特定の著者用に新しい書籍を1つ追加する作業が以下のように一行でできるようになりました。
@book = @author.books.create(published_at: Time.now)
著者と、その著者の書籍をまとめて削除する作業はさらに簡単です。
@author.destroy
その他の関連付け方法については、次の節をお読みください。それに続いて、関連付けに関するさまざまなヒントや活用方法、Railsの関連付けメソッドとオプションの完全な参照物もご紹介します。
Railsでサポートされている関連付けは以下の6種類です。
belongs_tohas_onehas_manyhas_many :throughhas_one :throughhas_and_belongs_to_many関連付けは、一種のマクロ的な呼び出しとして実装されており、これによってモデル間の関連付けを宣言的に追加できます。たとえば、あるモデルが他のモデルに従属している(belongs_to)と宣言すると、2つのモデルのそれぞれのインスタンス間で「主キー - 外部キー」情報を保持しておくようにRailsに指示が伝わります。同時に、いくつかの便利なメソッドもそのモデルに追加されます。
本ガイドではこの後、それぞれの関連付けの宣言方法と利用方法について詳しく解説します。その前に、それぞれの関連付けが適切となる状況について簡単にご紹介しましょう。
belongs_to関連付けあるモデルでbelongs_to関連付けを行なうと、他方のモデルとの間に「1対1」のつながりが設定されます。このとき、宣言を行ったモデルのすべてのインスタンスは、他方のモデルのインスタンスに「従属(belongs to)」します。たとえば、Railsアプリケーションに著者(Author)と書籍(Book)情報が含まれており、１冊の書籍につき正確に１人の著者を割り当てたいのであれば、Bookモデルで以下のように宣言します。
class Book < ApplicationRecord belongs_to :author end
belongs_to関連付けで指定するモデル名は必ず「単数形」にしなければなりません。上記の例で、Bookモデルのauthor関連付けを複数形（authors）にしてからBook.create(authors: @author)でインスタンスを作成しようとすると、「uninitialized constant Book::Authors」エラーが発生します。Railsは、関連付けの名前から自動的にモデルのクラス名を推測します。従って、関連付け名が誤って複数形になってしまっていると、そこから推測されるクラス名も誤った形の複数形になってしまいます。
上の関連付けに対応するマイグレーションは以下のような感じになります。
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
has_one関連付けhas_one関連付けも、他方のモデルとの間に1対1の関連付けを設定します。しかし、その意味と結果はbelongs_toとは若干異なります。has_one関連付けの場合は、その宣言が行われているモデルのインスタンスが、他方のモデルのインスタンスを「まるごと含んでいる」または「所有している」ことを示します。たとえば、供給者(supplier)1人につきアカウント(account)を1つだけ持つという関係があるのであれば、以下のように宣言を行います。
class Supplier < ApplicationRecord has_one :account end
上の関連付けに対応するマイグレーションは以下のような感じになります。
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
ユースケースにもよりますが、アカウントとの関連付けのために、供給者のカラムに一意のインデックスや外部キー制約を追加する必要もある場合もあります。その場合、カラムの定義は次のようになる可能性があります。
create_table :accounts do |t| t.belongs_to :supplier, index: { unique: true }, foreign_key: true # ... end
has_many関連付けhas_many関連付けは、他のモデルとの間に「1対多」のつながりがあることを示します。has_many関連付けが使われている場合、「反対側」のモデルでは多くの場合belongs_toが使われます。has_many関連付けが使われている場合、そのモデルのインスタンスは、反対側のモデルの「0個以上の」インスタンスを所有します。たとえば、著者(Author)と書籍(Book)を含むRailsアプリケーションでは、著者のモデルを以下のように宣言できます。
class Author < ApplicationRecord has_many :books end
has_many関連付けを宣言する場合、相手のモデル名は「複数形」にする必要があります。
上の関連付けに対応するマイグレーションは以下のような感じになります。
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
has_many :through関連付けhas_many :through関連付けは、他方のモデルと「多対多」のつながりを設定する場合によく使われます。この関連付けは、2つのモデルの間に「第3のモデル」(joinモデル)が介在する点が特徴です。それによって、相手モデルの「0個以上」のインスタンスとマッチします。たとえば、患者(patient)が医師(physician)との診察予約(appointment)を取る医療業務を考えてみます。この場合、関連付けは次のような感じになるでしょう。
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
上の関連付けに対応するマイグレーションは以下のような感じになります。
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
joinモデル(結合モデル)のコレクションは、has_many経由で管理できます。たとえば、以下のような割り当てを実行したとします。
physician.patients = patients
このとき、新たに関連付けられたオブジェクトについて、新しいjoinモデルが自動的に作成されます。結合時に不足している部分があれば、その行はjoinモデルから削除され、joinモデルに含まれなくなります。
モデル結合時の不足分自動削除は即座に行われます。さらに、その際にdestroyコールバックはトリガーされませんので注意が必要です。
has_many :through関連付けは、ネストしたhas_many関連付けを介して「ショートカット」を設定する場合にも便利です。たとえば、1つのドキュメントに多くの節(section)があり、1つの節の下に多くの段落(paragraph)がある状態で、節をスキップしてドキュメントの下のすべての段落の単純なコレクションが欲しいとします。その場合、以下の方法で設定できます。
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
through: :sectionsと指定することにより、Railsは以下の文を理解できるようになります。
@document.paragraphs
has_one :through関連付けhas_one :through関連付けは、他方のモデルに対して「1対1」のつながりを設定します。この関連付けは、2つのモデルの間に「第3のモデル」(joinモデル)が介在する点が特徴です。それによって、相手モデルの1つのインスタンスとマッチします。たとえば、1人の提供者(supplier)が1つのアカウントに関連付けられ、さらに1つのアカウントが1つのアカウント履歴に関連付けられる場合、supplierモデルは以下のような感じになります。
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
上の関連付けに対応するマイグレーションは以下のような感じになります。
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
has_and_belongs_to_many関連付けhas_and_belongs_to_many関連付けは、他方のモデルと「多対多」のつながりを作成しますが、through:を指定した場合と異なり、第3のモデル(joinモデル)が介在しません(訳注: 後述するように結合用のテーブルは必要です)。たとえば、アプリケーションに完成品(assembly)と部品(part)があり、1つの完成品に多数の部品が対応し、逆に1つの部品にも多くの完成品が対応するのであれば、モデルの宣言は以下のようになります。
class Assembly < ApplicationRecord has_and_belongs_to_many :parts end class Part < ApplicationRecord has_and_belongs_to_many :assemblies end
上の関連付けに対応するマイグレーションは以下のような感じになります。
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
belongs_toとhas_oneのどちらを選ぶか2つのモデルの間に1対1の関係を作りたいのであれば、いずれか一方のモデルにbelongs_toを追加し、もう一方のモデルにhas_oneを追加する必要があります。どちらの関連付けをどちらのモデルに置けばよいのでしょうか。
区別の決め手となるのは外部キー(foreign key)をどちらに置くかです(外部キーは、belongs_toを追加した方のモデルのテーブルに追加されます)。もちろんこれだけでは決められません。データの実際の意味についてもう少し考えてみる必要があります。has_oneというリレーションは、主語となるものが目的語となるものを「所有している」ということを表しています。そして、所有されている側(目的語)の方が、所有している側(主語)を指し示しているということも表しています。たとえば、「供給者がアカウントを持っている」とみなす方が、「アカウントが供給者を持っている」と考えるよりも自然です。つまり、この場合の正しい関係は以下のようになります。
class Supplier < ApplicationRecord has_one :account end class Account < ApplicationRecord belongs_to :supplier end
上の関連付けに対応するマイグレーションは以下のような感じになります。
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
マイグレーションでt.bigint :supplier_idのように「小文字のモデル名_id」と書くと、外部キーを明示的に指定できます。現在のバージョンのRailsでは、同じことをt.references :supplierという方法で記述できます。こちらの方が実装の詳細が抽象化され、隠蔽されます。
has_many :throughとhas_and_belongs_to_manyのどちらを選ぶかRailsでは、モデル間の多対多リレーションシップを宣言するのに2とおりの方法が利用できます。簡単なのはhas_and_belongs_to_manyを使う方法です。この方法では関連付けを直接指定できます。
class Assembly < ApplicationRecord has_and_belongs_to_many :parts end class Part < ApplicationRecord has_and_belongs_to_many :assemblies end
多対多のリレーションシップを宣言するもう1つの方法はhas_many :throughです。こちらの場合は、joinモデルによる間接的な関連付けが使われます。
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
どちらを使うかについてですが、経験上、リレーションシップのモデルそれ自体を独立したエンティティとして扱いたい(両モデルの関係そのものについて処理を行いたい)のであれば、中間にjoinモデルを使うhas_many :throughリレーションシップを選ぶのが最もシンプルです。リレーションシップのモデルで何か特別なことをする必要がまったくないのであれば、joinモデルの不要なhas_and_belongs_to_manyリレーションシップを使うのがシンプルです(ただし、こちらの場合はjoinモデルが不要な代わりに、専用のjoinテーブルを別途データベースに作成しておく必要がありますので、お忘れなきよう)。
joinモデルで検証(validation)、コールバック、追加の属性が必要な場合は、has_many :throughをお使いください。
ポリモーフィック関連付けは、関連付けのやや高度な応用です。ポリモーフィック関連付けを使うと、ある1つのモデルが他の複数のモデルに属していることを、1つの関連付けだけで表現できます。たとえば、写真(picture)モデルがあり、このモデルを従業員(employee)モデルと製品(product)モデルの両方に従属させたいとします。この場合は以下のように宣言します。
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
ポリモーフィックなbelongs_toは、他のあらゆるモデルから利用できる、(デザインパターンで言うところの)インターフェイスを設定する宣言とみなすこともできます。@employee.picturesとすると、写真のコレクションをEmployeeモデルのインスタンスから取得できます。
同様に、@product.picturesとすれば写真のコレクションをProductモデルのインスタンスから取得できます。
Pictureモデルのインスタンスがあれば、@picture.imageableとすることで親を取得できます。これができるようにするためには、ポリモーフィックなインターフェイスを使うモデルで、外部キーのカラムと型のカラムを両方とも宣言しておく必要があります。
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
t.referencesという書式を使うとさらにシンプルにできます。
class CreatePictures < ActiveRecord::Migration[5.2] def change create_table :pictures do |t| t.string :name t.references :imageable, polymorphic: true t.timestamps end end end
データモデルを設計していると、時に自分自身に関連付けられる必要のあるモデルに出会うことがあります。たとえば、1つのデータベースモデルに全従業員を格納しておきたいが、マネージャーと部下(subordinate)の関係も追えるようにしておきたい場合が考えられます。この状況は、自己結合関連付けを用いてモデル化できます。
class Employee < ApplicationRecord has_many :subordinates, class_name: "Employee", foreign_key: "manager_id" belongs_to :manager, class_name: "Employee", optional: true end
上のように宣言しておくと、@employee.subordinatesと@employee.managerが使えるようになります。
マイグレーションおよびスキーマでは、モデル自身にreferencesカラムを追加します。
class CreateEmployees < ActiveRecord::Migration[5.0] def change create_table :employees do |t| t.references :manager t.timestamps end end end
RailsアプリケーションでActive Recordの関連付けを効率的に使うためには、以下について知っておく必要があります。
関連付けのメソッドは、すべてキャッシュを中心に構築されています。最後に実行したクエリの結果はキャッシュに保持され、次回以降の操作で利用できます。このキャッシュはメソッド間でも共有されることに注意してください。例:
author.books # データベースからbooksを取得する author.books.size # booksのキャッシュコピーが使われる author.books.empty? # booksのキャッシュコピーが使われる
データがアプリケーションの他の部分によって更新されている可能性に対応するために、キャッシュを再読み込みするにはどうしたらよいでしょうか。その場合は関連付けのメソッド呼び出しでreloadを指定するだけで、キャッシュが破棄されてデータが再読み込みされます。
author.books # データベースからbooksを取得する author.books.size # booksのキャッシュコピーが使われる author.books.reload.empty? # booksのキャッシュコピーが破棄される # その後データベースから再度読み込まれる
関連付けにはどんな名前でも使えるとは限りません。関連付けを作成すると、モデルにその名前のメソッドが追加されます。従って、ActiveRecord::Baseのインスタンスで既に使われているような名前を関連付けに使うのは禁物です。そのような名前を関連付けに使うと、基底メソッドが上書きされて不具合が生じる可能性があります。attributesやconnectionは関連付けに使ってはならない名前の例です。
関連付けはきわめて便利ですが、残念ながら全自動の魔法ではありません。関連付けを使うからには、関連付けの設定に合わせてデータベースのスキーマを常に更新しておく責任が生じます。作成した関連付けにもよりますが、具体的には次の2つの作業が必要になります。1. belongs_to関連付けを使う場合は、外部キーを作成する必要があります。2. has_and_belongs_to_many関連付けを使う場合は、適切なjoinテーブルを作成する必要があります。
belongs_to関連付けに対応する外部キーを作成するbelongs_to関連付けを宣言したら、対応する外部キーを作成する必要があります。以下のモデルを例にとります。
class Book < ApplicationRecord belongs_to :author end
上の宣言は、以下のようにbooksテーブル上の対応する外部キーカラムと整合している必要があります。作成した直後のテーブルの場合、マイグレーションは次のような感じになります。
class CreateBooks < ActiveRecord::Migration[5.0] def change create_table :books do |t| t.datetime :published_at t.string :book_number t.references :author end end end
一方、既存のテーブルの場合、マイグレーションは次のような感じになります。
class AddAuthorToBooks < ActiveRecord::Migration[5.0] def change add_reference :books, :author end end
データベースレベルでの参照整合性を強制するには、上の‘reference’カラム宣言にforeign_key: trueオプションを追加します。
has_and_belongs_to_many関連付けに対応するjoinテーブルを作成するhas_and_belongs_to_many関連付けを作成した場合は、それに対応するjoin(結合)テーブルを明示的に作成する必要があります。:join_tableオプションを使って明示的にjoinテーブルの名前が指定されていない場合、Active Recordは2つのクラス名を辞書の並び順に結合して、joinテーブル名を作成します。たとえばAuthorモデルとBookモデルを結合する場合、'a'は辞書で'b'より先に出現するので "authors_books"というデフォルトのjoinテーブル名が使われます。
モデル名の並び順はStringクラスの<=>演算子を用いて算出されます。これは、2つの文字列の長さが異なり、短い方が長い方の途中まで完全に一致しているような場合、長い方の文字列は短い方よりも辞書上の並び順が前として扱われるということです。たとえば、"paper_boxes" テーブルと "papers" テーブルがある場合、これらを結合すれば "papers_paper_boxes" となると推測されます。 "paper_boxes" の方が長いので、常識的には並び順が後ろになると予測できるからです。しかし実際のjoinテーブル名は "paper_boxes_papers" になってしまいます。これはアンダースコア '_' の方が 's' よりも並び順が前になるためです。
生成された名前がどのようなものであれ、適切なマイグレーションを実行してjoinテーブルを生成する必要があります。以下の関連付けを例にとって考えてみましょう。
class Assembly < ApplicationRecord has_and_belongs_to_many :parts end class Part < ApplicationRecord has_and_belongs_to_many :assemblies end
この関連付けに対応する assemblies_parts テーブルをマイグレーションで作成し、裏付けておく必要があります。このテーブルには主キーを設定しないでください。
class CreateAssembliesPartsJoinTable < ActiveRecord::Migration[5.0] def change create_table :assemblies_parts, id: false do |t| t.bigint :assembly_id t.bigint :part_id end add_index :assemblies_parts, :assembly_id add_index :assemblies_parts, :part_id end end
このテーブルはモデルを表さないので、create_tableにid: falseを渡します。こうしておかないとこの関連付けは正常に動作しません。モデルのIDが破損する、IDの競合で例外が発生するなど、has_and_belongs_to_many関連付けの動作が怪しい場合は、この設定を忘れていないかどうか再度確認してみてください。
create_join_tableメソッドを使うことも可能です。
class CreateAssembliesPartsJoinTable < ActiveRecord::Migration[5.0] def change create_join_table :assemblies, :parts do |t| t.index :assembly_id t.index :part_id end end end
デフォルトでは、関連付けによって探索されるオブジェクトは、現在のモジュールのスコープ内のものだけです。Active Recordモデルをモジュール内で宣言している場合、この点に注意する必要があります。例：
module MyApplication module Business class Supplier < ApplicationRecord has_one :account end class Account < ApplicationRecord belongs_to :supplier end end end
上のコードは正常に動作します。これは、SupplierクラスとAccountクラスが同じスコープ内で定義されているためです。しかし下のコードは動作しません。SupplierクラスとAccountクラスが異なるスコープ内で定義されているためです。
module MyApplication module Business class Supplier < ApplicationRecord has_one :account end end module Billing class Account < ApplicationRecord belongs_to :supplier end end end
あるモデルと異なる名前空間にあるモデルを関連付けるには、関連付けの宣言で完全なクラス名を指定する必要があります
module MyApplication module Business class Supplier < ApplicationRecord has_one :account, class_name: "MyApplication::Billing::Account" end end module Billing class Account < ApplicationRecord belongs_to :supplier, class_name: "MyApplication::Business::Supplier" end end end
関連付けは、通常双方向で設定します。2つのモデル両方に関連を定義する必要があります。
class Author < ApplicationRecord has_many :books end class Book < ApplicationRecord belongs_to :author end
Active Recordは関連付けの設定から、これら２つのモデルが双方向の関連を共有していることを自動的に認識します。以下に示すとおり、Active RecordはAuthorオブジェクトのコピーを１つだけ読み出し、アプリケーションをより効率的かつ一貫性のあるデータに仕上げます。
a = Author.first b = a.books.first a.first_name == b.author.first_name # => true a.first_name = 'David' a.first_name == b.author.first_name # => true
Active Recordでは標準的な名前同士の関連付けのほとんどをサポートしていて、自動的に認識できます。ただし、Active Recordでスコープや次のオプションを使った場合、双方向の関連付けは自動的に認識されません。
:through:foreign_keyたとえば、次のようなモデルを宣言したケースを考えてみましょう。
class Author < ApplicationRecord has_many :books end class Book < ApplicationRecord belongs_to :writer, class_name: 'Author', foreign_key: 'author_id' end
この場合、Active Recordは双方向の関連付けを自動的に認識しません。
a = Author.first b = a.books.first a.first_name == b.writer.first_name # => true a.first_name = 'David' a.first_name == b.writer.first_name # => false
Active Recordは:inverse_ofオプションを提供していて、これを使うと双方向の関連付けを明示的に宣言できます。
class Author < ApplicationRecord has_many :books, inverse_of: 'writer' end class Book < ApplicationRecord belongs_to :writer, class_name: 'Author', foreign_key: 'author_id' end
has_manyの関連付けを宣言するときに:inverse_ofオプションも含めることで、Active Recordは双方向の関連付けを認識するようになります。
a = Author.first b = a.books.first a.first_name == b.writer.first_name # => true a.first_name = 'David' a.first_name == b.writer.first_name # => true
この節では、各関連付けの詳細を解説します。関連付けの宣言によって追加されるメソッドやオプションについても説明します。
belongs_to関連付けの詳細belongs_to関連付けは、別のモデルとの間に1対1の関連付けを作成します。データベースの用語で説明すると、この関連付けが行われているクラスには外部キーがあるということです。外部キーが自分のクラスではなく相手のクラスにあるのであれば、belongs_toではなくhas_oneを使う必要があります。
belongs_toで追加されるメソッドbelongs_to関連付けを宣言したクラスでは、以下の6つのメソッドを自動的に利用できるようになります。
associationassociation=(associate)build_association(attributes = {})create_association(attributes = {})create_association!(attributes = {})reload_associationこれらのメソッドのうち、associationの部分はプレースホルダであり、belongs_toの最初の引数である関連付け名をシンボルにしたものに置き換えられます。例えば次のように宣言をした場合
class Book < ApplicationRecord belongs_to :author end
Bookモデルのインスタンスで以下のメソッドが使えるようになります。
author author= build_author create_author create_author! reload_author
新しく作成したhas_one関連付けまたはbelongs_to関連付けを初期化するには、build_で始まるメソッドを使う必要があります。この場合has_many関連付けやhas_and_belongs_to_many関連付けで使われるassociation.buildメソッドは使わないでください。作成するには、create_で始まるメソッドをお使いください。
associationassociationメソッドは関連付けられたオブジェクトを返します。関連付けられたオブジェクトがない場合はnilを返します。
@author = @book.author
関連付けられたオブジェクトがデータベースから検索されたことがある場合は、キャッシュされたものを返します。キャッシュを読み出さずにデータベースから直接読み込ませたい場合は、親オブジェクトが持つ#reload_associationメソッドを呼び出します。
@author = @book.reload_author
association=(associate)association=メソッドは、引数のオブジェクトをそのオブジェクトに関連付けます。その背後では、関連付けられたオブジェクトから主キーを取り出し、そのオブジェクトの外部キーにその同じ値を設定しています。
@book.author = @author
build_association(attributes = {})build_associationメソッドは、関連付けられた型の新しいオブジェクトを返します。返されるオブジェクトは、渡された属性に基いてインスタンス化され、外部キーを経由するリンクが設定されます。関連付けられたオブジェクトは、値が返された時点ではまだ保存されていないことにご注意ください。
@author = @book.build_author(author_number: 123, author_name: "John Doe")
create_association(attributes = {})create_associationメソッドは、関連付けられた型の新しいオブジェクトを返します。このオブジェクトは、渡された属性を用いてインスタンス化され、そのオブジェクトの外部キーを介してリンクが設定されます。そして、関連付けられたモデルで指定されている検証がすべてパスすると、この関連付けられたオブジェクトは保存されます。
@author = @book.create_author(author_number: 123, author_name: "John Doe")
create_association!(attributes = {})上のcreate_associationと同じですが、レコードがinvalidの場合にActiveRecord::RecordInvalidがraiseされる点が異なります。
belongs_toのオプションRailsのデフォルトのbelongs_to関連付けは、ほとんどの場合カスタマイズ不要ですが、関連付けの動作をカスタマイズしたい場合もあります。これは、作成するときに渡すオプションとスコープブロックで簡単にカスタマイズできます。たとえば、以下のようなオプションを関連付けに追加できます。
class Book < ApplicationRecord belongs_to :author, touch: :books_updated_at, counter_cache: true end
belongs_to関連付けでは以下のオプションがサポートされています。
:autosave:class_name:counter_cache:dependent:foreign_key:primary_key:inverse_of:polymorphic:touch:validate:optional:autosave:autosaveオプションをtrueに設定すると、親オブジェクトが保存されるたびに、読み込まれているすべての関連付けメンバを保存し、destroyフラグが立っているメンバを破棄します。:autosaveをfalseに設定することと、:autosaveオプションを未設定のままにしておくことは同じではありません。:autosaveが存在しない場合、関連付けられたオブジェクトのうち、新しいオブジェクトは保存されますが、更新されたオブジェクトは保存されません。
:class_name関連名から関連相手のオブジェクト名を生成できない事情がある場合、:class_nameオプションを用いてモデル名を直接指定できます。たとえば、書籍(book)が著者(author)に従属しているが実際の著者のモデル名がPatronである場合には、以下のように指定します。
class Book < ApplicationRecord belongs_to :author, class_name: "Patron" end
:counter_cache:counter_cacheオプションは、従属しているオブジェクトの数の検索効率を向上させます。以下のモデルで説明します。
class Book < ApplicationRecord belongs_to :author end class Author < ApplicationRecord has_many :books end
上の宣言のままでは、@author.books.sizeの値を知るためにデータベースに対してCOUNT(*)クエリを実行する必要があります。この呼び出しを避けるために、「従属している方のモデル(belongs_toを宣言している方のモデル)」にカウンタキャッシュを追加できます。
class Book < ApplicationRecord belongs_to :author, counter_cache: true end class Author < ApplicationRecord has_many :books end
上のように宣言すると、キャッシュ値が最新の状態に保たれ、次にsizeメソッドが呼び出されたときにその値が返されます。
ここで1つ注意が必要です。:counter_cacheオプションはbelongs_to宣言で指定しますが、実際に数を数えたいカラムは「相手の」モデル(関連付けられているモデル)の方に追加する必要があります。上の場合には、Authorモデルの方にbooks_countカラムを追加する必要があります。
counter_cacheオプションでtrueの代わりに任意のカラム名を設定すると、デフォルトのカラム名をオーバーライドできます。以下は、books_countの代わりにcount_of_booksを設定した場合の例です。
class Book < ApplicationRecord belongs_to :author, counter_cache: :count_of_books end class Author < ApplicationRecord has_many :books end
belongs_toの関連付けをする時に、:counter_cacheオプションを設定する必要があります。
カウンタキャッシュ用のカラムは、attr_readonlyによって読み出し専用属性となるモデルのリストに追加されます。
:dependent:dependentで指定するオプションの挙動は以下のとおりです。
:destroy: オブジェクトが削除されるときに、関連付けられたオブジェクトのdestroyメソッドが実行されます。:delete: オブジェクトが削除されるときに、関連付けられたオブジェクトが直接データベースから削除されます。destroyメソッドは実行されません。このオプションは、他のクラスのhas_many関連付けとつながりのあるbelongs_to関連付けに対して使ってはいけません。孤立したレコードがデータベースに残ってしまう可能性があります。
:foreign_keyRailsの慣例では、相手のモデルを指す外部キーを保持しているjoinテーブル上のカラム名については、そのモデル名にサフィックス_idを追加した関連付け名が使われることを前提とします。:foreign_keyオプションを使えば、外部キーの名前を直接指定できます。
class Book < ApplicationRecord belongs_to :author, class_name: "Patron", foreign_key: "patron_id" end
Railsは外部キーのカラムを自動的に作成することはありません。外部キーを使うには、マイグレーションで明示的に定義する必要があります。
:primary_keyRailsの慣例では、idカラムはそのテーブルの主キーとして使われます。:primary_keyオプションを指定すると、指定された別のカラムを主キーとして設定できます
たとえば、 usersテーブルにguidという主キーがあるとします。そのguidカラムに、別のtodosテーブルの外部キーであるuser_idカラムを使いたい場合は、次のようにprimary_keyを設定します。
class User < ApplicationRecord self.primary_key = 'guid' # 主キーがguidになる end class Todo < ApplicationRecord belongs_to :user, primary_key: 'guid' end
@user.todos.createを実行すると、@todoレコードはuser_idを@userのguidとして持つようになります。
:inverse_of:inverse_ofオプションは、その関連付けの逆関連付けとなるhas_many関連付けまたはhas_one関連付けの名前を指定します。
class Author < ApplicationRecord has_many :books, inverse_of: :author end class Book < ApplicationRecord belongs_to :author, inverse_of: :books end
:polymorphic:polymorphicオプションにtrueを指定すると、ポリモーフィック関連付けを指定できます。ポリモーフィック関連付けの詳細についてはこのガイドの説明を参照してください。
:touch:touchオプションをtrueに設定すると、そのオブジェクトがsaveまたはdestroyされたときに、関連付けられたオブジェクトのupdated_atタイムスタンプやupdated_onタイムスタンプが常に現在の時刻に設定されます。
class Book < ApplicationRecord belongs_to :author, touch: true end class Author < ApplicationRecord has_many :books end
上の例の場合、Bookクラスは、関連付けられているAuthorのタイムスタンプを保存時またはdestroy時に更新します。更新時に特定のタイムスタンプ属性を指定することもできます。
class Book < ApplicationRecord belongs_to :author, touch: :books_updated_at end
:validate:validateオプションをtrueに設定すると、関連付けられたオブジェクトが保存時に必ず検証(validation)されます。デフォルトはfalseであり、この場合関連付けられたオブジェクトは保存時に検証されません。
:optional:optionalオプションをtrueに設定すると、関連付けされたオブジェクトの存在性のバリデーションが実行されないようになります。デフォルトではこのオプションはfalseとなっています。
belongs_toのスコープbelongs_toで使われるクエリをカスタマイズしたい場合があります。スコープブロックを用いてこのようなカスタマイズを行えます。以下に例を示します。
class Book < ApplicationRecord belongs_to :author, -> { where active: true } end
スコープブロック内では標準のクエリメソッドをすべて利用できます。ここでは以下について説明します。
whereincludesreadonlyselectwherewhereは、関連付けられるオブジェクトが満たすべき条件を指定します。
class Book < ApplicationRecord belongs_to :author, -> { where active: true } end
includesincludesメソッドを使うと、その関連付けが使われるときにeager-load (訳注:preloadとは異なる)しておきたい第2関連付けを指定できます。以下のモデルを例に考えてみましょう。
class Chapter < ApplicationRecord belongs_to :book end class Book < ApplicationRecord belongs_to :author has_many :chapters end class Author < ApplicationRecord has_many :books end
chaptersから著者名(Author)を@chapter.book.authorのように直接取り出す頻度が高い場合は、chapterからbookへの関連付けを行なう時にAuthorをあらかじめincludesしておくと、無駄なクエリが減って効率が高まります。
class Chapter < ApplicationRecord belongs_to :book, -> { includes :author } end class Book < ApplicationRecord belongs_to :author has_many :chapters end class Author < ApplicationRecord has_many :books end
直接の関連付けではincludesを使う必要はありません。Book belongs_to :authorのような直接の関連付けでは必要に応じて自動的にeager-loadされます。
readonlyreadonlyを指定すると、関連付けられたオブジェクトから取り出した内容は読み出し専用になります。
selectselectメソッドを使うと、関連付けられたオブジェクトのデータ取り出しに使われるSQLのSELECT句を上書きします。Railsはデフォルトではすべてのカラムを取り出します。
selectをbelongs_to関連付けで使う場合、正しい結果を得るために:foreign_keyオプションを必ず設定してください。
association.nil?メソッドを用いて、関連付けられたオブジェクトが存在するかどうかを確認できます。
if @book.author.nil? @msg = "この本の著者が見つかりません" end
オブジェクトをbelongs_to関連付けに割り当てても、そのオブジェクトが自動的に保存されるわけではありません。関連付けられたオブジェクトが保存されることもありません。
has_one関連付けの詳細has_one関連付けは他のモデルと1対1対応します。データベースの観点では、この関連付けでは相手のクラスが外部キーを持ちます。相手ではなく自分のクラスが外部キーを持っているのであれば、belongs_toを使うべきです。
has_oneで追加されるメソッドhas_one関連付けを宣言したクラスでは、以下の6つのメソッドを自動的に利用できるようになります。
associationassociation=(associate)build_association(attributes = {})create_association(attributes = {})create_association!(attributes = {})reload_associationこれらのメソッドのうち、associationの部分はプレースホルダであり、has_oneの最初の引数である関連付け名をシンボルにしたものに置き換えられます。たとえば以下の宣言を見てみましょう。
class Supplier < ApplicationRecord has_one :account end
これにより、Supplierモデルのインスタンスで以下のメソッドが使えるようになります。
account account= build_account create_account create_account! reload_account
新しく作成したhas_one関連付けまたはbelongs_to関連付けを初期化するには、build_で始まるメソッドを使う必要があります。この場合has_many関連付けやhas_and_belongs_to_many関連付けで使われるassociation.buildメソッドは使わないでください。作成するには、create_で始まるメソッドをお使いください。
associationassociationメソッドは関連付けられたオブジェクトを返します。関連付けられたオブジェクトがない場合はnilを返します。
@account = @supplier.account
関連付けられたオブジェクトがデータベースから検索されたことがある場合は、キャッシュされたものを返します。キャッシュを読み出さずにデータベースから直接読み込ませたい場合は、親オブジェクトが持つ#reload_associationメソッドを呼び出します。
@account = @supplier.reload_account
association=(associate)association=メソッドは、引数のオブジェクトをそのオブジェクトに関連付けます。その背後では、そのオブジェクトから主キーを取り出し、関連付けるオブジェクトの外部キーの値をその主キーと同じ値にします。
@supplier.account = @account
build_association(attributes = {})build_associationメソッドは、関連付けられた型の新しいオブジェクトを返します。このオブジェクトは、渡された属性でインスタンス化され、そのオブジェクトの外部キーを介してリンクが設定されます。ただし、関連付けられたオブジェクトはまだ保存されません。
@account = @supplier.build_account(terms: "Net 30")
create_association(attributes = {})create_associationメソッドは、関連付けられた型の新しいオブジェクトを返します。このオブジェクトは、渡された属性を用いてインスタンス化され、そのオブジェクトの外部キーを介してリンクが設定されます。そして、関連付けられたモデルで指定されている検証がすべてパスすると、この関連付けられたオブジェクトは保存されます。
@account = @supplier.create_account(terms: "Net 30")
create_association!(attributes = {})上のcreate_associationと同じですが、レコードがinvalidの場合にActiveRecord::RecordInvalidがraiseされる点が異なります。
has_oneのオプションRailsのデフォルトのhas_one関連付けは、ほとんどの場合カスタマイズ不要ですが、時には関連付けの動作をカスタマイズしたくなることもあると思います。これは、作成するときにオプションを渡すことで簡単にカスタマイズできます。たとえば、以下のようなオプションを関連付けに追加できます。
class Supplier < ApplicationRecord has_one :account, class_name: "Billing", dependent: :nullify end
has_one関連付けでは以下のオプションがサポートされます。
:as:autosave:class_name:dependent:foreign_key:inverse_of:primary_key:source:source_type:through:validate:as:asオプションを設定すると、ポリモーフィック関連付けを指定できます。ポリモーフィック関連付けの詳細についてはこのガイドの説明を参照してください。
:autosave:autosaveオプションをtrueに設定すると、親オブジェクトが保存されるたびに、読み込まれているすべてのメンバを保存し、destroyフラグが立っているメンバを破棄します。:autosaveをfalseに設定することと、:autosaveオプションを未設定のままにしておくことは同じではありません。:autosaveが存在しない場合、関連付けられたオブジェクトのうち、新しいオブジェクトは保存されますが、更新されたオブジェクトは保存されません。
:class_name関連名から関連相手のオブジェクト名を生成できない事情がある場合、:class_nameオプションを用いてモデル名を直接指定できます。たとえば、Supplierにアカウントが1つあり、アカウントを含むモデルの実際の名前がAccountではなくBillingになっている場合、以下のようにモデル名を指定できます。
class Supplier < ApplicationRecord has_one :account, class_name: "Billing" end
:dependentオブジェクトのオーナーがdestroyされたときの、それに関連付けられたオブジェクトの扱いを制御します。
:destroyを指定すると、関連付けられたオブジェクトも同時にdestroyされます。:deleteを指定すると、関連付けられたオブジェクトはデータベースから直接削除されます。このときコールバックは実行されません。:nullifyを指定すると、外部キーがNULLに設定されます。ポリモーフィックなtypeカラムもポリモーフィック関連付けでNULLに設定されます。コールバックは実行されません。:restrict_with_exceptionを指定すると、関連付けられたレコードがある場合にActiveRecord::DeleteRestrictionError例外が発生します。:restrict_with_errorを指定すると、関連付けられたオブジェクトがある場合にエラーがオーナーに追加されます。NOT NULLデータベース制約のある関連付けでは、:nullifyオプションを与えないようにする必要があります。そのような関連付けをdestroyするdependentを設定しなかった場合、関連付けられたオブジェクトを変更できなくなってしまいます。これは、最初に関連付けられたオブジェクトの外部キーがNULL値になってしまい、この値は許されていないためです。
:foreign_keyRailsの慣例では、相手のモデル上の外部キーを保持しているカラム名については、そのモデル名にサフィックス_idを追加した関連付け名が使われることを前提とします。:foreign_keyオプションを使うと外部キーの名前を直接指定できます。
class Supplier < ApplicationRecord has_one :account, foreign_key: "supp_id" end
Railsは外部キーのカラムを自動的に作成することはありません。外部キーを使うには、マイグレーションで明示的に定義する必要があります。
:inverse_of:inverse_ofオプションは、その関連付けの逆関連付けとなるbelongs_to関連付けの名前を指定します。
class Supplier < ApplicationRecord has_one :account, inverse_of: :supplier end class Account < ApplicationRecord belongs_to :supplier, inverse_of: :account end
:primary_keyRailsの慣例では、モデルの主キーはidカラムに保存されていることを前提とします。:primary_keyオプションで主キーを明示的に指定することでこれを上書きできます。
:source:sourceオプションは、has_one :through関連付けにおける「ソースの」関連付け名、つまり関連付け元の名前を指定します。
:source_type:source_typeオプションは、ポリモーフィック関連付けを介して行われるhas_one :through関連付けにおける「ソースの」関連付けタイプ、つまり関連付け元のタイプを指定します。
class Book < ApplicationRecord has_one :format, polymorphic: true has_one :dust_jacket, through: :format, source: :dust_jacket, source_type: "Hardback" end class Paperback < ApplicationRecord; end class Hardback < ApplicationRecord has_one :dust_jacket end class DustJacket < ApplicationRecord; end
:through:throughオプションは、このガイドで既に説明したhas_one :through関連付けのクエリを実行する際に経由するjoinモデルを指定します。
:touch:touchオプションをtrueに設定すると、そのオブジェクトがsaveまたはdestroyされたときに、関連付けられたオブジェクトのupdated_atタイムスタンプやupdated_onタイムスタンプが常に現在の時刻に設定されます。
class Supplier < ApplicationRecord has_one :account, touch: true end class Account < ApplicationRecord belongs_to :supplier end
上の場合、supplierをsaveした場合もdestroyした場合も、関連付けられたaccountでタイムスタンプが更新されます。この更新で特定のタイムスタンプ属性を指定することもできます。
class Supplier < ApplicationRecord has_one :account, touch: :suppliers_updated_at end
:validate:validateオプションをtrueに設定すると、関連付けられたオブジェクトが保存時に必ず検証(validation)されます。デフォルトはfalseであり、この場合関連付けられたオブジェクトは保存時に検証されません。
has_oneのスコープについてhas_oneで使われるクエリをカスタマイズしたい場合があります。スコープブロックを用いてこのようなカスタマイズを行えます。以下に例を示します。
class Supplier < ApplicationRecord has_one :account, -> { where active: true } end
スコープブロック内では標準のクエリメソッドをすべて利用できます。ここでは以下について説明します。
whereincludesreadonlyselectwherewhereは、関連付けられるオブジェクトが満たすべき条件を指定します。
class Supplier < ApplicationRecord has_one :account, -> { where "confirmed = 1" } end
includesincludesメソッドを使うと、その関連付けが使われるときにeager-loadすべき第2関連付けを指定できます。以下のモデルを例に考えてみましょう。
class Supplier < ApplicationRecord has_one :account end class Account < ApplicationRecord belongs_to :supplier belongs_to :representative end class Representative < ApplicationRecord has_many :accounts end
上の例で、Supplierから代表(Representative)を@supplier.account.representativeのように直接取り出す頻度が高い場合は、SupplierからAccountへの関連付けにRepresentativeをあらかじめincludeしておくと、無駄なクエリが減って効率が高まります。
class Supplier < ApplicationRecord has_one :account, -> { includes :representative } end class Account < ApplicationRecord belongs_to :supplier belongs_to :representative end class Representative < ApplicationRecord has_many :accounts end
readonlyreadonlyを指定すると、関連付けられたオブジェクトを取り出すときに読み出し専用になります。
selectselectメソッドを使うと、関連付けられたオブジェクトのデータ取り出しに使われるSQLのSELECT句を上書きします。Railsはデフォルトではすべてのカラムを取り出します。
association.nil?メソッドを用いて、関連付けられたオブジェクトが存在するかどうかを確認できます。
if @supplier.account.nil? @msg = "No account found for this supplier" end
has_one関連付けにオブジェクトをアサインすると、外部キーを更新するためにそのオブジェクトは自動的に保存されます。さらに、置き換えられるオブジェクトは、これは外部キーが変更されたことによってすべて自動的に保存されます。
関連付けられているオブジェクト同士のいずれか一方が検証(validation)のために保存に失敗すると、アサインの状態からはfalseが返され、アサインはキャンセルされます。
親オブジェクト(has_one関連付けを宣言している側のオブジェクト)が保存されない場合(つまりnew_record?がtrueを返す場合)、子オブジェクトは追加時に保存されません。親オブジェクトが保存された場合は、子オブジェクトは保存されます。
has_one関連付けにオブジェクトをアサインし、しかもそのオブジェクトを保存したくない場合、build_associationメソッドをお使いください。
has_many関連付けの詳細has_many関連付けは、他のモデルとの間に「1対多」のつながりを作成します。データベースの観点では、この関連付けにおいては相手のクラスが外部キーを持ちます。この外部キーは相手のクラスのインスタンスを参照します。
has_manyで追加されるメソッドhas_many関連付けを宣言したクラスでは、以下の17のメソッドを自動的に利用できるようになります。
collectioncollection<<(object, ...)collection.delete(object, ...)collection.destroy(object, ...)collection=(objects)collection_singular_idscollection_singular_ids=(ids)collection.clearcollection.empty?collection.sizecollection.find(...)collection.where(...)collection.exists?(...)collection.build(attributes = {}, ...)collection.create(attributes = {})collection.create!(attributes = {})collection.reload上のメソッドのcollectionの部分はプレースホルダであり、実際にはhas_manyへの1番目の引数として渡されたシンボルに置き換えられます。また、collection_singularの部分はシンボルの単数形に置き換えられます。たとえば以下の宣言を見てみましょう。
class Author < ApplicationRecord has_many :books end
これにより、Authorモデルのインスタンスで以下のメソッドが使えるようになります。
books books<<(object, ...) books.delete(object, ...) books.destroy(object, ...) books=(objects) book_ids book_ids=(ids) books.clear books.empty? books.size books.find(...) books.where(...) books.exists?(...) books.build(attributes = {}, ...) books.create(attributes = {}) books.create!(attributes = {}) books.reload
collectioncollectionメソッドは、関連付けられたすべてのオブジェクトのリレーションを返します。関連付けられたオブジェクトがない場合は、空のリレーションを1つ返します。
@books = @author.books
collection<<(object, ...)collection<<メソッドは、1つ以上のオブジェクトをコレクションに追加します。このとき、追加されるオブジェクトの外部キーは、呼び出し側モデルの主キーに設定されます。
@author.books << @book1
collection.delete(object, ...)collection.deleteメソッドは、外部キーをNULLに設定することで、コレクションから1つまたは複数のオブジェクトを削除します。
@author.books.delete(@book1)
削除のされ方はこれだけではありません。オブジェクト同士がdependent: :destroyで関連付けられている場合はdestroyされますが、オブジェクト同士がdependent: :delete_allで関連付けられている場合はdeleteされますのでご注意ください。
collection.destroy(object, ...)collection.destroyは、コレクションに関連付けられているオブジェクトに対してdestroyを実行することで、コレクションから1つまたは複数のオブジェクトを削除します。
@author.books.destroy(@book1)
この場合オブジェクトは無条件でデータベースから削除されます。このとき、:dependentオプションがどのように設定されていても無視して削除が行われます。
collection=(objects)collection=メソッドは、指定したオブジェクトでそのコレクションの内容を置き換えます。元からあったオブジェクトは削除されます。この変更はデータベースの中で存続します。
collection_singular_idscollection_singular_idsメソッドは、そのコレクションに含まれるオブジェクトのidを配列にしたものを返します。
@book_ids = @author.book_ids
collection_singular_ids=(ids)collection_singular_ids=メソッドは、指定された主キーidを持つオブジェクトの集まりでコレクションの内容を置き換えます。元からあったオブジェクトは削除されます。この変更はデータベースで永続化されます。
collection.clearcollection.clearメソッドは、dependentオプションによって指定された手法に従って、コレクションからすべてのオブジェクトを削除します。もしオプションが渡されていなかった場合、デフォルトの手法に従います。デフォルトでは、has_many :throughの関連付けの場合はdelete_allが渡され、has_manyの関連付けの場合は外部キーにNULLがセットされます。
@author.books.clear
dependent: :delete_allの場合と同様に、オブジェクトがdependent: :destroyで関連付けされていた場合、それらのオブジェクトは削除されます。
collection.empty?collection.empty?メソッドは、関連付けられたオブジェクトがコレクションの中に1つもない場合にtrueを返します。
<% if @author.books.empty? %> No Books Found <% end %>
collection.sizecollection.sizeメソッドは、コレクションに含まれるオブジェクトの数を返します。
@book_count = @author.books.size
collection.find(...)collection.findメソッドは、コレクションに含まれるオブジェクトを検索します。このメソッドの構文は、
ActiveRecord::Base.findで使われているものと同じです。
@available_book = @author.books.find(1)
collection.where(...)collection.whereメソッドは、コレクションに含まれているメソッドを指定された条件に基いて検索します。このメソッドではオブジェクトは遅延読み込み(lazy load)される点にご注意ください。つまり、オブジェクトに実際にアクセスが行われる時にだけデータベースへのクエリが発生します。
@available_books = @author.books.where(available: true) # No query yet @available_book = @available_books.first # Now the database will be queried
collection.exists?(...)collection.exists?メソッドは、指定された条件に合うオブジェクトがコレクションの中に存在するかどうかをチェックします。このメソッドの構文は、ActiveRecord::Base.exists?で使われているものと同じです。
collection.build(attributes = {}, ...)collection.buildメソッドは、関連付けが行われた1つのオブジェクトまたはオブジェクトの配列を返します。返されるオブジェクトは、渡された属性に基いてインスタンス化され、外部キーを経由するリンクが作成されます。関連付けられたオブジェクトは、値が返された時点ではまだ保存されていないことにご注意ください。
@book = @author.books.build(published_at: Time.now, book_number: "A12345") @books = @author.books.build([ { published_at: Time.now, book_number: "A12346" }, { published_at: Time.now, book_number: "A12347" } ...
collection.create(attributes = {})collection.createメソッドは、関連付けが行われた新しい1つのオブジェクトまたは新しいオブジェクトの配列を返します。このオブジェクトは、渡された属性を用いてインスタンス化され、そのオブジェクトの外部キーを介してリンクが作成されます。そして、関連付けられたモデルで指定されている検証がすべてパスすると、この関連付けられたオブジェクトは保存されます。
@book = @author.books.create(published_at: Time.now, book_number: "A12345") @books = @author.books.create([ { published_at: Time.now, book_number: "A12346" }, { published_at: Time.now, book_number: "A12347" } ...
collection.create!(attributes = {})上のcollection.createと同じですが、レコードがinvalidの場合にActiveRecord::RecordInvalidがraiseされる点が異なります。
collection.reloadcollection.reloadメソッドは、関連付けられたすべてのオブジェクトのリレーションを1つ返し、データベースを強制的に読み出します。関連付けられたオブジェクトがない場合は、空のリレーションを1つ返します。
@books = @author.books.reload
has_manyのオプションRailsのデフォルトのhas_many関連付けは、ほとんどの場合カスタマイズ不要ですが、時には関連付けの動作をカスタマイズしたくなることもあると思います。これは、作成するときにオプションを渡すことで簡単にカスタマイズできます。たとえば、以下のようなオプションを関連付けに追加できます。
class Author < ApplicationRecord has_many :books, dependent: :delete_all, validate: false end
has_many関連付けでは以下のオプションがサポートされます。
:as:autosave:class_name:counter_cache:dependent:foreign_key:inverse_of:primary_key:source:source_type:through:validate:as:asオプションを設定すると、ポリモーフィック関連付けであることが指定されます。(このガイドの説明を参照)
:autosave:autosaveオプションをtrueに設定すると、親オブジェクトが保存されるたびに、読み込まれているすべてのメンバを保存し、destroyフラグが立っているメンバを破棄します。:autosaveをfalseに設定することと、:autosaveオプションを未設定のままにしておくことは同じではありません。:autosaveが存在しない場合、関連付けられたオブジェクトのうち、新しいオブジェクトは保存されますが、更新されたオブジェクトは保存されません。
:class_name関連名から関連相手のオブジェクト名を生成できない事情がある場合、:class_nameオプションを用いてモデル名を直接指定できます。たとえば、1人の著者(author)が複数の書籍(books)を持っているが、実際の書籍モデル名がTransactionである場合には以下のように指定します。
class Author < ApplicationRecord has_many :books, class_name: "Transaction" end
:counter_cacheこのオプションは、:counter_cacheオプションを任意の名前に変更したい場合に使います。このオプションは、belongs_toの関連付けで:counter_cacheの名前を変更したときにのみ必要になります。
:dependentオーナーオブジェクトがdestroyされたときに、オーナーに関連付けられたオブジェクトをどうするかを制御します。
:destroyを指定すると、関連付けられたオブジェクトもすべて同時にdestroyされます。:delete_allを指定すると、関連付けられたオブジェクトはすべてデータベースから直接削除されます。このときコールバックは実行されません。:nullifyを指定すると、外部キーはNULLに設定されます。ポリモーフィックなtypeカラムもポリモーフィック関連付けでNULLに設定されます。コールバックは実行されません。:restrict_with_exceptionを指定すると、関連付けられたレコードが1つでもある場合にActiveRecord::DeleteRestrictionError例外が発生します。:restrict_with_errorを指定すると、関連付けられたオブジェクトが1つでもある場合にエラーがオーナーに追加されます。:destroyオプションや:delete_allオプションは、collection.deleteメソッドやcollection=メソッドのセマンティクス（意味）にも影響します（コレクションから削除されると、関連付けられたオブジェクトもdestroyされます）。
:foreign_keyRailsの慣例では、相手のモデル上の外部キーを保持しているカラム名については、そのモデル名にサフィックス _id を追加した関連付け名が使われることを前提とします。:foreign_keyオプションを使うと外部キーの名前を直接指定できます。
class Author < ApplicationRecord has_many :books, foreign_key: "cust_id" end
Railsは外部キーのカラムを自動的に作成することはありません。外部キーを使うには、マイグレーションで明示的に定義する必要があります。
:inverse_of:inverse_ofオプションは、その関連付けの逆関連付けとなるbelongs_to関連付けの名前を指定します。
class Author < ApplicationRecord has_many :books, inverse_of: :author end class Book < ApplicationRecord belongs_to :author, inverse_of: :books end
:primary_keyRailsの慣例では、関連付けの主キーはidカラムに保存されていることを前提とします。:primary_keyオプションで主キーを明示的に指定することでこれを上書きできます。
usersテーブルに主キーとしてidカラムがあり、その他にguidカラムもあるとします。要件として、todosテーブルが (idではなく) guidカラムの値を外部キーとして使いたいとします。これは以下のようにすることで実現できます。
class User < ApplicationRecord has_many :todos, primary_key: :guid end
@todo = @user.todos.createを実行すると、@todoレコードのuser_idの値は @userのguidになります。
:source:sourceオプションは、has_many :through関連付けにおける「ソースの」関連付け名、つまり関連付け元の名前を指定します。このオプションは、関連付け名から関連付け元の名前が自動的に推論できない場合以外には使う必要はありません。
:source_type:source_typeオプションは、ポリモーフィック関連付けを介して行われるhas_many :through関連付けにおける「ソースの」関連付けタイプ、つまり関連付け元のタイプを指定します。
class Author < ApplicationRecord has_many :books has_many :paperbacks, through: :books, source: :format, source_type: "Paperback" end class Book < ApplicationRecord has_one :format, polymorphic: true end class Hardback < ApplicationRecord; end class Paperback < ApplicationRecord; end
:through:throughオプションは、このガイドで既に説明したhas_one :through関連付けのクエリを実行する際に経由するjoinモデルを指定します。
:validate:validateオプションをfalseに設定すると、関連付けられたオブジェクトは保存時に検証(validation)されません。デフォルトはtrueであり、この場合関連付けられたオブジェクトは保存時に検証されます。
has_manyのスコープについてhas_manyで使われるクエリをカスタマイズしたい場合があります。スコープブロックを用いてこのようなカスタマイズを行えます。以下に例を示します。
class Author < ApplicationRecord has_many :books, -> { where processed: true } end
スコープブロック内では標準のクエリメソッドをすべて利用できます。ここでは以下について説明します。
whereextendinggroupincludeslimitoffsetorderreadonlyselectdistinctwherewhereは、関連付けられるオブジェクトが満たすべき条件を指定します。
class Author < ApplicationRecord has_many :confirmed_books, -> { where "confirmed = 1" }, class_name: "Book" end
条件はハッシュで指定することもできます。
class Author < ApplicationRecord has_many :confirmed_books, -> { where confirmed: true }, class_name: "Book" end
whereオプションでハッシュを用いた場合、この関連付けで作成されたレコードは自動的にこのハッシュを使うスコープに含まれるようになります。この例の場合、@author.confirmed_books.createまたは@author.confirmed_books.buildを実行すると、confirmedカラムの値がtrueの書籍(book)が常に作成されます。
extendingextendingメソッドは、関連付けプロキシを拡張する名前付きモジュールを指定します。関連付けの拡張については後述します。
groupgroupメソッドは、結果をグループ化する際の属性名を1つ指定します。内部的にはSQLのGROUP BY句が使われます。
class Author < ApplicationRecord has_many :chapters, -> { group 'books.id' }, through: :books end
includesincludesメソッドを使うと、その関連付けが使われるときにeager-loadされるべき第2関連付けを指定できます。以下のモデルを例に考えてみましょう。
class Author < ApplicationRecord has_many :chapters end class Chapter < ApplicationRecord belongs_to :book end
chaptersを著者名(Author)から@author.books.chaptersのように直接取り出す頻度が高い場合は、AuthorからBookへの関連付けを行なう時にchaptersをあらかじめincludesしておくと、無駄なクエリが減って効率が高まります。
class Author < ApplicationRecord has_many :books, -> { includes :chapters } end class Book < ApplicationRecord belongs_to :author has_many :chapters end class Chapter < ApplicationRecord belongs_to :book end
limitlimitメソッドは、関連付けを用いて取得できるオブジェクトの総数の上限を指定するのに使います。
class Author < ApplicationRecord has_many :recent_books, -> { order('published_at desc').limit(100) }, class_name: "Book" end
offsetoffsetメソッドは、関連付けを用いてオブジェクトを取得する際の開始オフセットを指定します。たとえば、-> { offset(11) }と指定すると、最初の11レコードはスキップされ、12レコード目から返されるようになります。
orderorderメソッドは、関連付けられたオブジェクトに与えられる順序を指定します。内部的にはSQLのORDER BY句が使われます。
class Author < ApplicationRecord has_many :books, -> { order "date_confirmed DESC" } end
readonlyreadonlyを指定すると、関連付けられたオブジェクトを取り出すときに読み出し専用になります。
selectselectメソッドを使うと、関連付けられたオブジェクトのデータ取り出しに使われるSQLのSELECT句を上書きします。Railsはデフォルトではすべてのカラムを取り出します。
独自のselectメソッドを使う場合には、関連付けられているモデルの主キーカラムと外部キーカラムを必ず含めておいてください。これを行わなかった場合、Railsでエラーが発生します。
distinctdistinctメソッドは、コレクション内で重複が発生しないようにします。
このメソッドは:throughオプションと併用するときに特に便利です。
class Person < ApplicationRecord has_many :readings has_many :articles, through: :readings end person = Person.create(name: 'John') article = Article.create(name: 'a1') person.articles << article person.articles << article person.articles.inspect # => [#<Article id: 5, name: "a1">, #<Article id: 5, name: "a1">] Reading.all.inspect # => [#<Reading id: 12, person_id: 5, article_id: 5>, #<Reading id: 13, person_id: 5, article_id: 5>]
上の例の場合、readingが2つあって重複しており、person.articlesを実行すると、どちらも同じ記事を指しているにもかかわらず、両方とも取り出されてしまいます。
今度はdistinctを設定してみましょう。
class Person has_many :readings has_many :articles, -> { distinct }, through: :readings end person = Person.create(name: 'Honda') article = Article.create(name: 'a1') person.articles << article person.articles << article person.articles.inspect # => [#<Article id: 7, name: "a1">] Reading.all.inspect # => [#<Reading id: 16, person_id: 7, article_id: 7>, #<Reading id: 17, person_id: 7, article_id: 7>]
上の例でもreadingは2つあって重複しています。一方で、person.articlesを実行すると、１つのarticleのみを表示します。これはコレクションが一意のレコードのみを読み出しているからです。
挿入時にも同様に、現在残っているすべてのレコードが一意であるようにする (関連付けを検査したときに重複レコードが決して発生しないようにする) には、テーブル自体に一意のインデックスを追加する必要があります。たとえばreadingsというテーブルがあるとすると、記事を1人のpersonに1回しか追加できないようにするには、マイグレーションに以下を追加します。
add_index :readings, [:person_id, :article_id], unique: true
インデックスがユニークになると、ある記事をpersonに２回追加しようとすると
ActiveRecord::RecordNotUniqueエラーが発生するようになります
person = Person.create(name: 'Honda') article = Article.create(name: 'a1') person.articles << article person.articles << article # => ActiveRecord::RecordNotUnique
なお、include?などを用いて一意性をチェックすると競合が発生しやすいので注意が必要です。関連付けで強制的に一意にする目的でinclude?を使わないでください。たとえば上のarticleの場合、以下のコードで競合が発生しやすくなります。これは、複数のユーザーが同時にこのコードを実行する可能性があるためです。
person.articles << article unless person.articles.include?(article)
has_many関連付けにオブジェクトをアサインすると、外部キーを更新するためにそのオブジェクトは自動的に保存されます。1つの文で複数のオブジェクトをアサインすると、それらはすべて保存されます。
関連付けられているオブジェクトの1つでも検証(validation)エラーで保存に失敗すると、アサインの式からはfalseが返され、アサインはキャンセルされます。
親オブジェクト(has_many関連付けを宣言している側のオブジェクト)が保存されない場合(つまりnew_record?がtrueを返す場合)、子オブジェクトは追加時に保存されません。親オブジェクトが保存されると、関連付けられていたオブジェクトのうち保存されていなかったメンバはすべて保存されます。
has_many関連付けにオブジェクトをアサインし、しかもそのオブジェクトを保存したくない場合、collection.buildメソッドをお使いください。
has_and_belongs_to_many関連付けの詳細has_and_belongs_to_many関連付けは、他のモデルとの間に「多対多」のつながりを作成します。データベースの観点では、2つのクラスは中間でjoinテーブルを介して関連付けられます。このjoinテーブルには、両方のクラスを指す外部キーがそれぞれ含まれます。
has_and_belongs_to_manyで追加されるメソッドhas_and_belongs_to_many関連付けを宣言したクラスでは、以下の17のメソッドを自動的に利用できるようになります。
collectioncollection<<(object, ...)collection.delete(object, ...)collection.destroy(object, ...)collection=(objects)collection_singular_idscollection_singular_ids=(ids)collection.clearcollection.empty?collection.sizecollection.find(...)collection.where(...)collection.exists?(...)collection.build(attributes = {})collection.create(attributes = {})collection.create!(attributes = {})collection.reload上のメソッドのcollectionの部分はプレースホルダであり、実際にはhas_and_belongs_to_manyへの1番目の引数として渡されたシンボルに置き換えられます。また、collection_singularの部分はシンボルの単数形に置き換えられます。たとえば以下の宣言を見てみましょう。
class Part < ApplicationRecord has_and_belongs_to_many :assemblies end
これにより、Partモデルのインスタンスで以下のメソッドが使えるようになります。
assemblies assemblies<<(object, ...) assemblies.delete(object, ...) assemblies.destroy(object, ...) assemblies=(objects) assembly_ids assembly_ids=(ids) assemblies.clear assemblies.empty? assemblies.size assemblies.find(...) assemblies.where(...) assemblies.exists?(...) assemblies.build(attributes = {}, ...) assemblies.create(attributes = {}) assemblies.create!(attributes = {}) assemblies.reload
has_and_belongs_to_many関連付けで利用している中間のjoinテーブルが、2つの外部キー以外に何かカラムを含んでいる場合、これらのカラムは関連付けを介して取り出されるレコードに属性として追加されます。属性が追加されたレコードは常に読み出し専用になります。このようにして読み出された属性に対する変更は保存できないためです。
has_and_belongs_to_many関連付けで使うjoinテーブルにこのような余分なカラムを追加することはお勧めできません。2つのモデルを多対多で結合するjoinテーブルでこのような複雑な振る舞いが必要になるのであれば、has_and_belongs_to_manyではなくhas_many :throughをお使いください。
collectioncollectionメソッドは、関連付けられたすべてのオブジェクトのリレーションを1つ返します。関連付けられたオブジェクトがない場合は、空のリレーションを1つ返します。
@assemblies = @part.assemblies
collection<<(object, ...)collection<<メソッドは、joinテーブル上でレコードを作成し、それによって1つまたは複数のオブジェクトをコレクションに追加します。
@part.assemblies << @assembly1
このメソッドはcollection.concatおよびcollection.pushのエイリアスです。
collection.delete(object, ...)collection.deleteメソッドは、joinテーブル上のレコードを削除し、それによって1つまたは複数のオブジェクトをコレクションから削除します。このメソッドを実行してもオブジェクトはdestroyされません。
@part.assemblies.delete(@assembly1)
collection.destroy(object, ...)collection.destroyメソッドは、joinテーブル上のレコードを削除することで、1つまたは複数のオブジェクトをコレクションから削除します。このメソッドを実行してもオブジェクトはdestroyされません。
@part.assemblies.destroy(@assembly1)
collection=(objects)collection=メソッドは、指定したオブジェクトでそのコレクションの内容を置き換えます。元からあったオブジェクトは削除されます。この変更はデータベースで永続化されます。
collection_singular_idscollection_singular_idsメソッドは、そのコレクションに含まれるオブジェクトのidを配列にしたものを返します。
@assembly_ids = @part.assembly_ids
collection_singular_ids=(ids)collection_singular_ids=メソッドは、指定された主キーidを持つオブジェクトの集まりでコレクションの内容を置き換えます。元からあったオブジェクトは削除されます。この変更はデータベースで永続化されます。
collection.clearcollection.clearメソッドは、joinテーブル上のレコードを削除し、それによってすべてのオブジェクトをコレクションから削除します。このメソッドを実行しても、関連付けられたオブジェクトはdestroyされません。
collection.empty?collection.empty?メソッドは、関連付けられたオブジェクトがコレクションに含まれていない場合にtrueを返します。
<% if @part.assemblies.empty? %> ※この部分はどのアセンブリでも使われません。 <% end %>
collection.sizecollection.sizeメソッドは、コレクションに含まれるオブジェクトの数を返します。
@assembly_count = @part.assemblies.size
collection.find(...)collection.findメソッドは、コレクションに含まれるオブジェクトを検索します。このメソッドの構文は、ActiveRecord::Base.findで使われているものと同じです。
@assembly = @part.assemblies.find(1)
collection.where(...)collection.whereメソッドは、コレクションに含まれているメソッドを指定された条件に基いて検索します。このメソッドではオブジェクトは遅延読み込み(lazy load)される点にご注意ください。つまり、オブジェクトに実際にアクセスが行われる時にだけデータベースへのクエリが発生します。
@new_assemblies = @part.assemblies.where("created_at > ?", 2.days.ago)
collection.exists?(...)collection.exists?メソッドは、指定された条件に合うオブジェクトがコレクションの中に存在するかどうかをチェックします。このメソッドの構文は、ActiveRecord::Base.exists?で使われているものと同じです。
collection.build(attributes = {})collection.buildメソッドは、関連付けが行われたオブジェクトを1つ返します。このオブジェクトは、渡された属性でインスタンス化され、そのjoinテーブルを介してリンクが作成されます。ただし、関連付けられたオブジェクトはこの時点では保存されていないことにご注意ください。
@assembly = @part.assemblies.build({assembly_name: "Transmission housing"})
collection.create(attributes = {})collection.createメソッドは、関連付けが行われたオブジェクトを1つ返します。このオブジェクトは、渡された属性を用いてインスタンス化され、joinテーブルを介してリンクが作成されます。そして、関連付けられたモデルで指定されている検証がすべてパスすると、この関連付けられたオブジェクトは保存されます。
@assembly = @part.assemblies.create({assembly_name: "Transmission housing"})
collection.create!(attributes = {})上のcollection.createと同じですが、レコードがinvalidの場合にActiveRecord::RecordInvalidがraiseされる点が異なります。
collection.reloadcollection.reloadメソッドは、関連付けられたすべてのオブジェクトのリレーションを1つ返し、データベースを強制的に読み出します。関連付けられたオブジェクトがない場合は、空のリレーションを1つ返します。
@assemblies = @part.assemblies.reload
has_and_belongs_to_manyのオプションRailsのデフォルトのhas_and_belongs_to_many関連付けは、ほとんどの場合カスタマイズ不要ですが、時には関連付けの動作をカスタマイズしたくなることもあると思います。これは、作成するときにオプションを渡すことで簡単にカスタマイズできます。たとえば、以下のようなオプションを関連付けに追加できます。
class Parts < ApplicationRecord has_and_belongs_to_many :assemblies, -> { readonly }, autosave: true end
has_and_belongs_to_many関連付けでは以下のオプションがサポートされます。
:association_foreign_key:autosave:class_name:foreign_key:join_table:validate:association_foreign_keyRailsの慣例では、相手のモデルを指す外部キーを保持しているjoinテーブル上のカラム名については、そのモデル名にサフィックス _id を追加した名前が使われることを前提とします。:association_foreign_keyオプションを使うと外部キーの名前を直接指定できます。
:foreign_keyオプションおよび:association_foreign_keyオプションは、多対多の自己結合を行いたいときに便利です。以下に例を示します。
class User < ApplicationRecord has_and_belongs_to_many :friends, class_name: "User", foreign_key: "this_user_id", association_foreign_key: "other_user_id" end
:autosave:autosaveオプションをtrueに設定すると、親オブジェクトが保存されるたびに、読み込まれているすべての関連付けられたメンバを保存し、destroyフラグが立っているメンバを破棄します。:autosaveをfalseに設定することと、:autosaveオプションを未設定のままにしておくことは同じではありません。:autosaveが存在しない場合、関連付けられたオブジェクトのうち、新しいオブジェクトは保存されますが、更新されたオブジェクトは保存されません。
:class_name関連名から関連相手のオブジェクト名を生成できない事情がある場合、:class_nameオプションを用いてモデル名を直接指定できます。たとえば、1つの部品(Part)が複数の組み立て(Assembly)で使われ、組み立てを含む実際のモデル名がGadgetである場合、次のように設定します。
class Parts < ApplicationRecord has_and_belongs_to_many :assemblies, class_name: "Gadget" end
:foreign_keyRailsの慣例では、そのモデルを指す外部キーを保持しているjoinテーブル上のカラム名については、そのモデル名にサフィックス _id を追加した名前が使われることを前提とします。:foreign_keyオプションを使うと外部キーの名前を直接指定できます。
class User < ApplicationRecord has_and_belongs_to_many :friends, class_name: "User", foreign_key: "this_user_id", association_foreign_key: "other_user_id" end
:join_table辞書順に基いて生成されたjoinテーブルのデフォルト名が気に入らない場合、:join_tableオプションを用いてデフォルトのテーブル名を上書きできます。
:validate:validateオプションをfalseに設定すると、関連付けられたオブジェクトは保存時に検証(validation)されません。デフォルトはtrueであり、この場合関連付けられたオブジェクトは保存時に検証されます。
has_and_belongs_to_manyのスコープについてhas_and_belongs_to_manyで使われるクエリをカスタマイズしたい場合があります。スコープブロックを用いてこのようなカスタマイズを行うことができます。以下に例を示します。
class Parts < ApplicationRecord has_and_belongs_to_many :assemblies, -> { where active: true } end
スコープブロック内では標準のクエリメソッドをすべて利用できます。ここでは以下について説明します。
whereextendinggroupincludeslimitoffsetorderreadonlyselectdistinctwherewhereは、関連付けられるオブジェクトが満たすべき条件を指定します。
class Parts < ApplicationRecord has_and_belongs_to_many :assemblies, -> { where "factory = 'Seattle'" } end
条件はハッシュで指定することもできます。
class Parts < ApplicationRecord has_and_belongs_to_many :assemblies, -> { where factory: 'Seattle' } end
whereオプションでハッシュを用いた場合、この関連付けで作成されたレコードは自動的にこのハッシュを使うスコープに含まれるようになります。この例の場合、@parts.assemblies.createまたは@parts.assemblies.buildを実行すると、factoryカラムにSeattleを持つオブジェクトが作成されます。
extendingextendingメソッドは、関連付けプロキシを拡張する名前付きモジュールを指定します。関連付けの拡張については後述します。
groupgroupメソッドは、結果をグループ化する際の属性名を1つ指定します。内部的にはSQLのGROUP BY句が使われます。
class Parts < ApplicationRecord has_and_belongs_to_many :assemblies, -> { group "factory" } end
includesincludesメソッドを使うと、その関連付けが使われるときにeager-load (訳注:preloadとは異なる)しておきたい第2関連付けを指定できます。
limitlimitメソッドは、関連付けを用いて取得できるオブジェクトの総数の上限を指定するのに使います。
class Parts < ApplicationRecord has_and_belongs_to_many :assemblies, -> { order("created_at DESC").limit(50) } end
offsetoffsetメソッドは、関連付けを用いてオブジェクトを取得する際の開始オフセットを指定します。たとえばoffset(11)と指定すると、最初の11レコードはスキップされ、12レコード目から返されるようになります。
orderorderメソッドは、関連付けられたオブジェクトに与えられる順序を指定します。内部的にはSQLのORDER BY句が使われます。
class Parts < ApplicationRecord has_and_belongs_to_many :assemblies, -> { order "assembly_name ASC" } end
readonlyreadonlyを指定すると、関連付けられたオブジェクトを取り出すときに読み出し専用になります。
selectselectメソッドを使うと、関連付けられたオブジェクトのデータ取り出しに使われるSQLのSELECT句を上書きします。Railsはデフォルトではすべてのカラムを取り出します。
distinctdistinctメソッドは、コレクション内の重複を削除します。
has_and_belongs_to_many関連付けにオブジェクトをアサインすると、joinテーブルを更新するためにそのオブジェクトは自動的に保存されます。1つの文で複数のオブジェクトをアサインすると、それらはすべて保存されます。
関連付けられているオブジェクト同士の1つでも検証(validation)のために保存に失敗すると、アサインの状態からはfalseが返され、アサインはキャンセルされます。
親オブジェクト(has_and_belongs_to_many関連付けを宣言している側のオブジェクト)が保存されない場合(つまりnew_record?がtrueを返す場合)、子オブジェクトは追加時に保存されません。親オブジェクトが保存されると、関連付けられていたオブジェクトのうち保存されていなかったメンバはすべて保存されます。
has_and_belongs_to_many関連付けにオブジェクトをアサインし、しかもそのオブジェクトを保存したくない場合、collection.buildメソッドをお使いください。
通常のコールバックは、Active Recordオブジェクトのライフサイクルの中でフックされます。これにより、オブジェクトのさまざまな場所でコールバックを実行できます。たとえば、:before_saveコールバックを使って、オブジェクトが保存される直前に何かを実行できます。
関連付けのコールバックも、上のような通常のコールバックとだいたい同じですが、(Active Recordオブジェクトではなく)コレクションのライフサイクルによってイベントがトリガされる点が異なります。以下の4つの関連付けコールバックを利用できます。
before_addafter_addbefore_removeafter_removeこれらのオプションを関連付けの宣言に追加することで、関連付けコールバックを定義できます。以下に例を示します。
class Author < ApplicationRecord has_many :books, before_add: :check_credit_limit def check_credit_limit(book) ... end end
Railsは、追加されるオブジェクトや削除されるオブジェクトをコールバックに(引数として)渡します。
1つのイベントで複数のコールバックを使いたい場合には、配列で渡します。
class Author < ApplicationRecord has_many :books, before_add: [:check_credit_limit, :calculate_shipping_charges] def check_credit_limit(book) ... end def calculate_shipping_charges(book) ... end end
before_addコールバックが例外を発生した場合、オブジェクトはコレクションに追加されません。同様に、before_removeで例外が発生した場合も、オブジェクトはコレクションに削除されません。
これらのコールバックは、関連付けられたオブジェクトが関連付けコレクションを介して追加または削除された場合にのみ呼び出されます。
# `before_add`コールバックがトリガーされる author.books << book author.books = [book, book2] # `before_add`コールバックはトリガーされない book.update(author_id: 1)
Railsは自動的に関連付けのプロキシオブジェクトをビルドしますが、開発者はこれをカスタマイズできます。無名モジュール(anonymous module)を用いてこれらのオブジェクトを拡張(検索、作成などのメソッドを追加)できます。以下に例を示します。
class Author < ApplicationRecord has_many :books do def find_by_book_prefix(book_number) find_by(category_id: book_number[0..2]) end end end
拡張をさまざまな関連付けで共有したい場合は、名前付きの拡張モジュールを使うこともできます。以下に例を示します。
module FindRecentExtension def find_recent where("created_at > ?", 5.days.ago) end end class Author < ApplicationRecord has_many :books, -> { extending FindRecentExtension } end class Supplier < ApplicationRecord has_many :deliveries, -> { extending FindRecentExtension } end
関連付けプロキシの内部を参照するには、proxy_associationアクセサにある以下の3つの属性を使います。
proxy_association.ownerは、関連付けを所有するオブジェクトを返します。proxy_association.reflectionは、関連付けを記述するリフレクションオブジェクトを返します。proxy_association.targetは、belongs_toまたはhas_one関連付けのオブジェクトを返すか、has_manyまたはhas_and_belongs_to_many関連付けオブジェクトのコレクションを返します。異なるモデル間でフィールドや振る舞いを共有したい場合があります。Carモデル、Motorcycleモデル、Bicycleモデルを持っていた場合を考えてみましょう。このときcolorやpriceといったフィールド、そしていくつかの関連メソッドを共有したい場合が考えられます。しかし、モデルごとに振る舞いやコントローラーが異なります。
Railsではこのような状況にも簡単に対応できます。まず、各モデルのベースとなるVehicleモデルを生成します。
$ rails generate model vehicle type:string color:string price:decimal{10.2}
"type"フィールドを追加している点にご注目ください。すべてのモデルはデータベース上のテーブルに保存されるため、Railsはこのカラムに該当するモデル名を保存します。この例では、カラムには "Car"、"Motorcycle"、もしくは"Bicycle"が保存されます。今回のシングルテーブル継承（STI: Single Table Inheritance）ではテーブルにこの"type"フィールドがないとうまく動きません。
次に、Vehicleモデルを継承して３つの各モデルを生成します。このとき、--parent=PARENTオプションを使って特定の親モデルを継承している点にご注目ください。このオプションを使うと（該当するテーブルが既に存在しているため）マイグレーションファイルを生成せずに済みます。
たとえばCarモデルの場合は以下のようになります。
$ rails generate model car --parent=Vehicle
生成されたモデルは次のようになります。
class Car < Vehicle end
これによってVehicleモデルに追加されたすべての振る舞いがCarモデルにも追加されるようになります。関連付けやpublicメソッドなども同様に追加されます。
この状態で新しく作成したCarを保存すると、typeフィールドに"Car"が代入されたデータがvehiclesテーブルに追加されます。
Car.create(color: 'Red', price: 10000)
なお、実際に発行されるSQLは次のようになります。
INSERT INTO "vehicles" ("type", "color", "price") VALUES ('Car', 'Red', 10000)
Carのレコードを取得するクエリを送信すると、vehiclesテーブル中のCarが検索されるようになります。
Car.all
実際のクエリは次のようになります。
SELECT "vehicles".* FROM "vehicles" WHERE "vehicles"."type" IN ('Car')
Railsガイドは GitHub の yasslab/railsguides.jp で管理・公開されております。本ガイドを読んで気になる文章や間違ったコードを見かけたら、気軽に Pull Request を出して頂けると嬉しいです。Pull Request の送り方については GitHub の README をご参照ください。
原著における間違いを見つけたら『Rails のドキュメントに貢献する』を参考にしながらぜひ Rails コミュニティに貢献してみてください 🛠💨✨
本ガイドの品質向上に向けて、皆さまのご協力が得られれば嬉しいです。
Railsガイド運営チーム (@RailsGuidesJP)
Railsガイドは下記の協賛企業から継続的な支援を受けています。支援・協賛にご興味あれば協賛プランからお問い合わせいただけると嬉しいです。
