らくだ🐫にもできるRailsチュートリアル|6.1

6章でやる事
ユーザー用のデータモデルの作成と、データを保存する手段の確保
→ユーザー登録を出来る様にする

6.1 Userモデル

Railsでは、データモデルとして扱うデフォルトのデータ構造のことをモデル (Model) と呼びます (1.3.3で言うMVCのMのことです)

railsの標準のデータ構造→model
こんな雰囲気でいいのかな?

railsではデータベースを使ってデータを長期保存している
→データベースとやり取りをしてデータオブジェクトの作成・保存・検索を行うメソッドが用意されている
→マイグレーション (Migration)機能により、データの機能をRubyで記述できる

マイグレーションとはなんぞ

migration→移行・移動 的な言葉
railsで言うマイグレーションとは
→データベースにテーブルを作成したり、既存のテーブルにカラムを追加するなどの変更を加えたりできる機能
→使用するデータベースがMySQLでもSQLiteでも対応できる
→専用のファイルを作成して実行する(詳細は後程)

リレーショナルデータベースとはなんぞ

関係データベース(リレーショナルデータベース)
考えないで感じましょう😊(ひとまず)

作業を始める前にブランチを切る
→$ git checkout -b modeling-users

6.1.1 データベースの移行

nameとemailの2つの属性を持つUserモデルを作成する
→保存したいデータ
 id(数字)・name(短い文字列)・email(短い文字列)

→対応するデータモデル案
(カラム名):(データ型)
id:integer 数列(整数)
name:string 文字列
email:string 文字列
これに沿ってモデルを作成する

マイグレーションファイルとはなんぞ

データベースに与える変更を定義したchangeメソッドの集まり
ファイル名の頭にタイムスタンプが付く

created_atとupdated_atとはなんぞ

それぞれ、そのデータの作成時刻・更新時刻を自動的に記録したタイムスタンプ

マジックカラム(MagicColumn)とはなんぞ

マジックカラム→予約語→プログラムでもともと「予約(設定)」されている単語
使われる予定がある単語なので変数名や関数名に定義できない

実際生成されるUserモデル

usersテーブル
(カラム名):(データ型)
id:integer
name:string
email:string
created_at:datetime
updated_at:datetime

マイグレーションの適用

マイグレーションはコマンドを入力することで実行され、データベースに変更を加える

初めてdb:migrateを実行した時にdb/development.sqlite3という名前のファイルが生成される
→SQLite5データベースの実体
(DB Browser for SQLiteと言うツールを使用してデータベースの構造を見ることが出来る)
(本文参照にて)

演習

  1. Railsはdb/ディレクトリの中にあるschema.rbというファイルを使っています。これはデータベースの構造 (スキーマ (schema) と呼びます) を追跡するために使われます。さて、あなたの環境にあるdb/schema.rbの内容を調べ、その内容とマイグレーションファイル (リスト 6.2) の内容を比べてみてください。
  2. ほぼすべてのマイグレーションは、元に戻すことが可能です (少なくとも本チュートリアルにおいてはすべてのマイグレーションを元に戻すことができます)。元に戻すことを「ロールバック (rollback)と呼び、Railsではdb:rollbackというコマンドで実現できます。
    上のコマンドを実行後、db/schema.rbの内容を調べてみて、ロールバックが成功したかどうか確認してみてください (コラム 3.1ではマイグレーションに関する他のテクニックもまとめているので、参考にしてみてください)。上のコマンドでは、データベースからusersテーブルを削除するためにdrop_tableコマンドを内部で呼び出しています。これがうまくいくのは、drop_tableとcreate_tableがそれぞれ対応していることをchangeメソッドが知っているからです。この対応関係を知っているため、ロールバック用の逆方向のマイグレーションを簡単に実現することができるのです。なお、あるカラムを削除するような不可逆なマイグレーションの場合は、changeメソッドの代わりに、upとdownのメソッドを別々に定義する必要があります。詳細については、Railsガイドの「Active Record マイグレーション」を参照してください。
  3. もう一度rails db:migrateコマンドを実行し、db/schema.rbの内容が元に戻ったことを確認してください。

1.

内容はほぼ同じ
force: :cascade→外部キーが適切であればスキーマが再読み込みできるようにするための記述
外部キー→他のテーブルと結びつけるためのキー(ざっくり)
スキーマ→データベースの構造(ざっくり)
(このあたりの用語を念頭に感じ取る!)
2.3.は動作確認のみにて省略

6.1.2 modelファイル

Modelファイルの確認

演習

  1. Railsコンソールを開き、User.newでUserクラスのオブジェクトが生成されること、そしてそのオブジェクトがApplicationRecordを継承していることを確認してみてください (ヒント: 4.4.4で紹介したテクニックを使ってみてください)。
  2. 同様にして、ApplicationRecordがActiveRecord::Baseを継承していることについて確認してみてください。

6.1.3 ユーザーオブジェクトを作成する

sandboxモード →データベースに変更を加えたくないときに使用

オブジェクトが本当に削除されているか、などの検索方法は次項で

演習

  1. user.nameとuser.emailが、どちらもStringクラスのインスタンスであることを確認してみてください。
  2. created_atとupdated_atは、どのクラスのインスタンスでしょう

6.1.4 ユーザーオブジェクトを検索する

様々な検索方法

演習

  1. nameを使ってユーザーオブジェクトを検索してみてください。また、 find_by_nameメソッドが使えることも確認してみてください (古いRailsアプリケーションでは、古いタイプのfind_byをよく見かけることでしょう)。
  2. 実用的な目的のため、User.allはまるで配列のように扱うことができますが、実際には配列ではありません。User.allで生成されるオブジェクトを調べ、ArrayクラスではなくUser::ActiveRecord_Relationクラスであることを確認してみてください。
  3. User.allに対してlengthメソッドを呼び出すと、その長さを求められることを確認してみてください (4.2.3)。

6.1.5 ユーザーオブジェクトを更新する

saveで保存をせずに再読み込みをすると変更が取り消される
(DBから情報を読み込むため)

update_attributesメソッド

属性のハッシュを受け取り、検証に成功した場合に更新と保存を同時に行うメソッド

演習

  1. userオブジェクトへの代入を使ってname属性を使って更新し、saveで保存してみてください。
  2. 今度はupdate_attributesを使って、email属性を更新および保存してみてください。
  3. 同様にして、マジックカラムであるcreated_atも直接更新できることを確認してみてください。ヒント: 更新するときは「1.year.ago」を使うと便利です。これはRails流の時間指定の1つで、現在の時刻から1年前の時間を算出してくれます。

まとめとか感想

Userモデルを作成して、
その後はコンソールでデータの作り方などを色々確認。
4章の時と似たような感じでしたね。

らくだ🐫にもできるRailsチュートリアルとは

「ド」が付く素人のらくだ🐫が勉強するRailsチュートリアルの学習記録です。
自分用に記録していますが、お役に立つことがあれば幸いです。

調べたとはいえらくだ🐫なりの解釈や説明が含まれます。間違っている部分もあるかと思います。そんな所は教えて頂けますと幸いなのですが、このブログにはコメント機能がありません💧お手数おかけしますがTwitterなどでご連絡いただければ幸いです