MySQLを使用するための設定変更

RailsのデフォルトのDBはSQLiteになっています。
今回はMySQLを採用してDockerコンテナを立て、デフォルトの3306番ポートを開けてあるので、そこにアクセスできるようRails側の設定を変えたいです。
どうやらアプリケーション作成した時点でMySQLに指定できたらしいのですが、後からでも大丈夫とのこと。

以下のコマンドを実行すればOK。

$ rails db:system:change --to=mysql

/config/database.ymlを上書きしていいか聞かれるので、Yを返します。
これだけで

Gemfileの書き換え
configをMySQL用のデフォルト状態に上書き

してくれます。
Gemを書き換えたので

$ bundle install

もやっておきます。

このままでは個別のDBには適合していないので、ドキュメントに従って/config/database.ymlの開発用の設定箇所を書き換えます。

/config/database.yml

development:
  <<: *default
  database: testdb
  username: user
  password: pass

Railsのマイグレーションを使う

コマンドでファイル生成可能です。
（注意）次のパートでモデル生成のコマンドでマイグレーションファイルも一緒に生成できることが判明しました。そっちのコマンドの方が二度手間にならなくていいかも。

$ rails generate migration Task

/db/migrate/20230306154320_create_tasks.rb

class CreateTasks < ActiveRecord::Migration[7.0]
  def change
    create_table :tasks do |t|
      
      t.timestamps
    end
  end
end

こういう感じで生成されて、create_tableブロック内に追加するカラムを書いていきます。
書き方は上記ドキュメント参照。

/db/migrate/20230306154320_create_tasks.rb

class CreateTasks < ActiveRecord::Migration[7.0]
  def change
    create_table :tasks do |t|
      t.references :user, foreign_key: true
      t.string :name, :null => false
      t.datetime :limit, :null => false
      t.string :priority, :null => false
    end
  end
end

主キーについては何も指定しなければidカラムが生成され、主キーとなります。
※外部キー設定しているusersテーブルは先にマイグレーションファイル作成済みです。

マイグレーションの実行もコマンドで行います。

$ rails db:migrate

dry runはなさそうなので、一旦やってみてrails db:rollbackすればいいのだと思います、多分。

無事テーブルが作成され、/db/schema.rbというファイルが生成されました。
複数の環境間でスキーマの整合性を保つために使われるらしい。へーっ。（参考記事）
人間が見てもわかりやすくていいですね。

Active Recordのモデル実装

LaravelでいうEloquentみたいな感じ。いわゆるORMというやつで、SQLを直接書かずにデータベース操作するアレです。
コマンドでファイル生成。と、思ったら

$ rails generate model task
    invoke  active_record
    conflict    db/migrate/20230306204236_create_tasks.rb
Another migration is already named create_tasks: /achievelist/db/migrate/20230306154320_create_tasks.rb. Use --force to replace this migration or --skip to ignore conflicted file.

あー、マイグレーションのファイルも一緒に生成できたんですかそうですか。

$ rails generate model task --skip

これでコンフリクトしたマイグレーションファイルの生成はスキップしてくれます。助かった。

ModelとControllerの役割分担どんな感じ？

早速Modelを書いていきたいのですが、Active Record便利すぎてほぼ書くことなくないですか？
whereとかfindとかの条件もControllerに書いている人が多い気がします。ていうかそんなんControllerに書いておk？ユースケースとか挟まなくていいんですか？
その割にバリデーションはActive Recordの仕事みたいなこと書いてあるし。

うーん。
まず、今回の方針的にRailsに従う以上ControllerがActiveRecordに依存するのはもう仕方ないものとして諦めます。
とはいえ、全部が全部Controllerに書くのも本来MVCフレームワークとして存在するRailsの方針に合わないはずです。
なので、今回の開発では以下のような折衷案で進めることにしましょう。

ユースケース的に使い回すものは、シンプルな操作であってもModelにメソッドを書く
Modelにメソッドを置いたとしても単にActiveRecordを一度呼ぶだけになる場合はControllerに書く

利便性と保守性で妥協するとこんな感じかと思います。

Model実装

使い方その1 バリデーション

テーブルに保存する値のバリデーションをModelの機能として行ってくれます。
各バリデーションはドキュメント参照。

/app/models/task.rb

class Task < ApplicationRecord
  validates :user_id, numericality: true
  validates :name, length: { minimum: 1, maximum: 200 }
  validates :priority, inclusion: {
    in: %w[HIGH MIDDLE LOW)],
    message: '優先度は (HIGH MIDDLE LOW) から選択して下さい。'
  }
  validates :limit, datetime: {
    message: '正式な日時を入力してください。'
  }
end

呼び出すときは、newしてからvalid?するとバリデーションチェックしてくれます。

/app/controllers/api/v1/tasks_controller.rb

# (略)
task = Task.new({ user_id:, name:, limit:, priority: })

result =
  if !task.valid? # バリデーションを実行し、判定結果を真偽値で返却
    ResponseGenerator.validation_error(task.errors.full_messages) 
      # full_messagesでバリデーションエラーのメッセージ文字列の配列が取得できる
  elsif !task.save # テーブル保存を実行
    ResponseGenerator.db_error
  else
    ResponseGenerator.success
  end
# (略)

ResponseGeneratorというのは私が勝手に作った返却値生成用のモジュールです。一応以下のアコーディオンの中に置いておきます。

ResponseGenerator(参考)

/app/controllers/concerns/response_generator.rb

module ResponseGenerator
  extend ActiveSupport::Concern

  def success(body = nil)
    return if body.nil?

    {
      body:,
      status: 200
    }
  end

  def validation_error(errors = [])
    {
      body: {
        'title': 'params not validated.',
        'invalid-params': errors
      },
      status: 400
    }
  end

  def un_authorized_error
    {
      body: {
        'title': 'unauthorized.'
      },
      status: 401
    }
  end

  def not_found
    {
      body: {
        'title': 'resource not found.'
      },
      status: 404
    }
  end

  def db_error
    {
      body: {
        'title': 'db operations failed.'
      },
      status: 500
    }
  end

  module_function :success, :validation_error, :un_authorized_error, :not_found, :db_error
end

使い方その2 クラスメソッドの作成

Modelクラスに対して、クラスメソッドを定義することができます。selfをつけ忘れるとインスタンスメソッドになってしまうので注意。
目的は、一連の操作をモデルの役割としてメソッドにまとめることです。
以下は、クラスメソッド内部でトランザクションを使用してみた例です。トランザクション内で例外が発生するとロールバックしてくれる便利仕様、ありがとうございます。

/app/models/task_clear_event.rb

class TaskClearEvent < ApplicationRecord
  require 'date'

  def self.task_clear(task_id, user_id) # selfつけないとインスタンスメソッドになる
    # (略) cleared_taskとtaskはこの辺で定義してる
    transaction do # トランザクション開始
      cleared_task.save!
      task.destroy!

      event = new(
        {
          task_id: task.id,
          cleared_task_id: cleared_task.id,
          event_datetime: Time.current
        }
      )
      event.save!
    end # トランザクション終了

    !event.nil? && event.present?
  end
end

次回予告

今回はモデルを作成しました。次回はバックエンドで認証関係をやっていきたいと思います！