ActiveRecord

概要

Railsの利便性の源

データベース操作を完全に隠匿してRubyの世界の記述で完結させる

ActiveRecordを使わないのであればRailsを使う意味がないといっても過言じゃない

モデルオブジェクトはデータベースのカラムをあたかもRubyの属性のように扱えるようになる

ApplicationRecord < ActiveRecord::Base

hiroki.iconどんなSQLが発行されるか意識しておけば全然大丈夫。ただrailsから入門してSQLをあんまり意識する機会がない場合だと足元を撃ち抜きそう。

ARオブジェクトはそれなりに重いのを意識して実装する

pluck使うとか

機能

DB操作・読み込み

マイグレーション

Rubyオブジェクトへの変換

バリデーション

Validation

validatesメソッド

user.errors.full_messagesでバリデーションエラーをApplicativeに収集

/icons/重要.iconモデルでuniquenessで一意性を保証してもデータベースレベルでは一意性を保証していることにならない

シナリオ

素早く登録ボタンを二重クリック

モデルが二つ同時に作成される

この時点でオブジェクトでしかなくDBに永続化されていないので、どちらもuniq制約を突破する

どちらもsaveすることが可能になる

uniqueness制約だけでなくそのカラムに対してDBインデックスを作成すればDBレベルで一意性が保証されて解決

has_secure_password

モデルにpassword_digest属性を含んでいれば使える

hiroki.icon規約があらゆる場所にあって黒魔術的に感じる

code:ruby

class User < ApplicationRecord

before_save { email.downcase! }

validates :name, presence: true, length: { maximum: 50 }

VALID_EMAIL_REGEX = /\A\w+\-.+@a-z\d\-+(\.a-z\d\-+)*\.a-z+\z/i

validates :email, presence: true, length: { maximum: 255 },

format: { with: VALID_EMAIL_REGEX },

uniqueness: true

has_secure_password

validates :password, presence: true, length: { minimum: 6 }

end

コンテキスト付きでvalidation

validates :id, presence: true, unless: -> { validation_context == :tmp }

setting.valid?(:tmp)みたいな呼び出し方をした時のみ

CRUD

Update

複数属性を更新するのであればupdateメソッドで一気に更新するのが良い

一つの属性であれば、代入からのsave