Railsチュートリアル(第4版)の個人メモ
気になった部分、忘れそうな部分を記述。
- Ruby 2.6.1
- Rails 5.1.6
前章の最後 (5.4) でUsersコントローラを作成した。そのつづき。
6〜12章にかけて、ユーザ認証の各機能について作成していく。
6章ではこのうち、ユーザのデータモデル、保存について扱われている。
※ おわび
ナレッジになりきれていないメモをQiitaに上げるのが違うような気がしてきたが、
記事として所感を上げれば、それなりに反応があり、勉強にもなったため、お目汚しにはなりますが何卒ご容赦を。
そして最近Rails書いてないのだが下書が埋まってきたので放流。
6章 ユーザーのモデルを作成する
Railsでは認証を実装するための仕組みが既に整っているが、サービスごとに認証には多くのカスタムが必要になる。
このため、車輪の再発明にはなるが、方法を知っていればサードパーティ製の認証も実装しやすくなるので、Railsチュートリアルでは車輪を再発明している。
6.1 Userモデル
Railsは、データモデルとして扱うデフォルトのデータ構造を Model
(MVCのM) と呼ぶ。
このModelとのやり取りにはRailsデフォルトでは Active Record
というものが使われる。
これはSQLを意識せずにCRUDや構築を行ってくれるもの。
6.1.1 データベースの移行
データベースを永続化するためにUserモデルを作成。
Usersコントローラ作成時と同様、 $ rails g
する。
注意として、
コントローラは 複数形 Users
モデルは 単数形 User
とするのが慣習。
$ rails g model User name:string email:string
DBで使う属性(DBでいうカラム名)と、型を :
を挟んで渡す。
諸々生成されるが、 db/migrate/
には タイムスタンプ_create_モデル名s.rb
というファイルができる。
ここでDB作成のための情報が定義される。
class CreateUsers < ActiveRecord::Migration[5.0]
def change
create_table :users do |t|
t.string :name
t.string :email
t.timestamps
end
end
end
idとタイムスタンプについては、特に指定なしでも自動で用意される。
クラス名の部分を見ると、 ActiveRecord::Migration[5.0]
を継承しているらしい。
(Railsチュートでは5.0だが、小生の環境は5.1の表記)
timestamps
は、タイムスタンプに係る2つのカラム [ created_at
, updated_at
] を作成してくれる。
mysqlだとこんなかんじだろうか。
CREATE DATABASE User;
USE Users;
CREATE TABLE users(
id INT PRIMARY KEY AUTO_INCREMENT,
name VARCHAR(300),
email VARCHAR(300),
created_at TIMESTAMP NOT NULL CURRENT_TIMESTAMP,
updated_at TIMESTAMP NOT NULL CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP
);
sql書くたびに大文字or小文字 許さないおじさんが発生しそうだな、とビクビクしながら書いている(前職にもいた)。
正直、今の御時世、すべて小文字でも問題ないんだとおもっている。
ちなみに前職では日付はvarchar()で書いてうわなにをするやめろ
マイグレーションを適用。
友人曰く、複数人開発で特に気を遣わんと爆死するコマンドだから、と念を押された。気をつけよう。
DB側はバージョン管理されてるわけではない。
$ rails db:migrate
6.1.2 modelファイル
演習
Railsコンソールで User.new
をし、どのような継承関係に有るのか確認した。
Userクラス
< ApplicationRecord
< ActiveRecord::Base
< Object
< BaseObject
6.1.3 ユーザーオブジェクトを作成する
railsコンソールのサンドボックスオプション
を使うと、DBへの変更を終了時にすべてロールバックしてくれる。
$ rails console --sandbox
この中での実験。
モデルを生成した際にuserクラスが生成され( app/model/
)、これが ActiveRecord
から継承されている。
以下使ったメソッド
valid?
: 有効性(Validity)の確認
save
: 保存
保存した際、 create_at
, update_at
にタイムスタンプが押される。
戻り値に、保存ができたかどうかのbool値が帰ってくる。
create
: User.new ではメモリ内に生成するだけだったが、生成と同時に保存する。
演習
User.create
user.name
ActiceSupport::timeWithZone
6.2 ユーザーを検証する
6.2.1 有効性を検証する
要はSQLでのカラム型指定みたいな話
:email
に対して、 Double
とか Boolean
は入らんとか。
以下4点
- 存在性 (presence)
- 長さ (length)
- フォーマット (format)
- 一意性 (uniqueness)
所感
- usersテーブルに削除フラグって要るような気がする。後で追加するのか?
- dbのmigrateファイル、いっつも書くidとかをよしなにやってくれるのもだし、varcharとかで文字数指定しなくて良いのだけでも楽。
- dbのmigrateファイル、変更が時系列で残ってくれるのがとても安心感ある。前職ではDBに変更掛けたときのSQLすら遺してなかった。