いーほろよいの技術ブログ

IT技術ブログになります。

Railsのマイグレーションファイルに外部キー制約はどう書くの?

はじめに

タイトル通り、Railsでモデルを作成する時にマイグレーションファイルが作成されますが、その時に外部キー制約を指定したい場合はどうするのか疑問に思ったので試してみました。

環境については後に記述するので一致しない方は別途ご自身で調べてみてください。

ある程度、開発に携わっている方なら、外部キー制約(FOREIGN KEY)をご存知かと思いますが、もし知らない方は下記を読んで外部キー制約の仕様について確認してみてください。(なぜ必要なのかも調べておくといいかも知れません。)

外部キー制約について

MySQL :: MySQL 5.6 リファレンスマニュアル :: 13.1.17.2 外部キー制約の使用

 

また、この辺の扱い方を詳しく書いているRailsのドキュメントが見当たらず(たぶん調べ方が悪いのだと思います...)、下記の記事が大変参考になりました。ありがとうございます。

参考にさせていただいた記事

suin.io

 

環境

Ruby on Rails4

MySQL5.7

 

手順

始める前に

あるプロジェクト管理テーブル(親テーブル)に紐付くタスクテーブル(子テーブル)という想定です。

親:projects

子:tasks

※外部キー制約の確認が目的なのでカラムを指定しません。

 

モデル作成

>bundler exec rails g model project

>bundler exec rails g model task

 

マイグレーションファイル編集

作成されたtasksのマイグレーションファイルを編集します。

>vi db/migrate/yyyymmddxxxxx_create_tasks.rb

class CreateTasks < ActiveRecord::Migration
  def change
    create_table :tasks do |t|
      t.references :project, foreign_key: true

      t.timestamps null: false
    end
  end
end

 

マイグレーション実行

>bundler exec rake db:migrate RAILS_ENV=development_root

 

作成されたテーブルの確認

mysqlクライアントでDBに接続してテーブル作成確認コマンドで確認してみましょう。

>mysql -uユーザー -p

>show create table table_name

希望通りにprojectsテーブルのidとtasksテーブルのproject_idが外部キー制約(FOREIGN KEY)になっております。

CREATE TABLE `projects` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `created_at` datetime NOT NULL,
  `updated_at` datetime NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci

CREATE TABLE `tasks` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `project_id` int(11) DEFAULT NULL,
  `created_at` datetime NOT NULL,
  `updated_at` datetime NOT NULL,
  PRIMARY KEY (`id`),
  KEY `fk_rails_02e851e3b7` (`project_id`),
  CONSTRAINT `fk_rails_02e851e3b7` FOREIGN KEY (`project_id`) REFERENCES `projects` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci

 

所感

いつものようにRailsのお作法に則って記述すれば全く難しい事はありません。

しかし、全てのシステムがこのようになっているとは限りません...

例えば

  • idカラムが存在しないテーブルと外部キー制約をする場合はどうかいたらいいのか
  • 外部キーの名前を指定できないのか

この辺はもう少し掘り下げて調べてみる必要があるかも知れません。

もしかしたら、モデルだけ作成してマイグレーションファイルは作成しないとか...

 

以上、最後まで読んでいただきありがとうございます。

Railsのモデル作成時にカラム指定をしてみた!

はじめに

お問い合わせフォームの時には特に考えてやっていなかったのですが、テーブル構築時に普通ならnot nullやデフォルト値の設定などすると思います。

今回はそんな設定をしてテーブル作成をしてみました。

 

手順

以前にもやったと思いますが、今後は"scaffold"を使用して一通り作成します。

scaffoldとmodelの違いがイマイチ分かりません...

>bundler exec rails g scaffold mogu code:string name:string zip:integer address:string telephone:integer

 

作成されたマイグレーションファイルを編集

お馴染みのマイグレーションファイルが生成されると思います。

先ほどのコマンドで"db/migrate/yyyymmddxxxxxx_create_mogus.rb"というファイルができます。

今回は下記の仕様でテーブルを作成したいと思います。

  • idカラムは使わない
  • idの代わりにcodeカラムをプライマリキー指定
  • codeの文字列は32文字がMax
  • zipカラムは20文字まで
  • addressカラムはデフォルト"Tokyo"
  • code, name, addressはnull不可

書き出すとこんな感じです。

class CreateMogus < ActiveRecord::Migration
  def change
    create_table(:mogus, :id=>false, :primary_key=>"code") do |t|
      t.string :code, null: false, limit:32
      t.string :name, null: false
      t.integer :zip, limit: 7
      t.string :address, null: false, default: 'Tokyo'
      t.integer :telephone

      t.timestamps null: false
    end
  end
end 

 

テーブル作成

>bundler exec rake db:migrate RAILS_ENV=development_root

 ※RAILS_ENV=development_rootは個人的に設定している値です。

確認

+------------+--------------+------+-----+---------+-------+
| Field      | Type         | Null | Key | Default | Extra |
+------------+--------------+------+-----+---------+-------+
| code       | varchar(32)  | NO   |     | NULL    |       |
| name       | varchar(255) | NO   |     | NULL    |       |
| zip        | bigint(20)   | YES  |     | NULL    |       |
| address    | varchar(255) | NO   |     | Tokyo   |       |
| telephone  | int(11)      | YES  |     | NULL    |       |
| created_at | datetime     | NO   |     | NULL    |       |
| updated_at | datetime     | NO   |     | NULL    |       |
+------------+--------------+------+-----+---------+-------+

 

個人的感想ですが、毎回テーブル作成する度にidカラムがデフォルトで用意されるのは気持ち悪いです。(古い人の考えだからかも知れませんが...)

この辺って文化的にどうなんでしょうか。

もし、優しくてRails=自分だという方は是非教えてください。

 

以上、最後まで読んでいただきありがとうございます。

 

 

 

 

【便利】いいツールありました。(anyenv)

Reactの記事を読んでいたらNode.jsのインストールの話になり、『ndenvとはあるのかな?』と検索していたら、もっと便利な『anyenv』を見つけました。

github.com

 

『*env』と付くものをインストールしようとすると大抵これで済みそうです。

便利です。ありがたいですね。

 

感想

最近、開発周りの環境が充実していて独自の機能実装をしない限りバックエンドだけに限って言えばコーディングする量が十数年前に比べて、だいぶ減っているかと思います。

寧ろフロントエンド、ミドルウェアエンジニア、DBエンジニアの方が大変かと思います。

もちろん、バックエンドエンジニアも暇と言う訳では無いです!色んな所に駆り出される人が多いでしょうから...

 

 

Ruby on Railsのお勉強 〜お問い合わせフォーム編(save) その7〜

はじめに

前回の作業でバリデーション(検証)が完了したので最後のデータ登録を試して見たいと思います。

↓バリデーションはこちら を参照ください。

e-horoyoi.hatenablog.com

 

やる事

...特に無し?

今回はただ単純に登録するだけなので特に難しい事はありません。

 

手順

thanksページまで遷移した前提で話を進めます。

因みにthanksページはこのように記述します。

class InquiryController < ApplicationController
  ... 中略 ...

  def thanks
    @inquiry = Inquiry.new(post_params)
    if @inquiry.save == false
      render template: 'inquiry/index'
    end
  end

  ... 中略 ...
end

たったこれだけでした。

save実行時にバリデーションが実行されるので、わざわざやる必要が無いそうです。

railsguides.jp

 

因みに、モデルに値を渡して初期化されるか確認するには、railsのコンソールで下記のようにコマンドできます。

>bundler exec rails console --sandbox

>inquiry = Inquiry.new(name: 'hoge_name', mail: 'hoge_mail@gmail.com', telephone: '12345')

=> #<Inquiry id: nil, name: "hoge_name", mail: "hoge_mail@gmail.com", telephone: "12345", created_at: nil, updated_at: nil>

 

だいぶ呆気ないのですが簡単なお問い合わせフォームで感覚を掴んでみる程度だと、こんなもんで登録できてしまいます。

 

課題

モデル

  • 書き方(ビジネスロジックとの住み分け)
  • 初期化(attr_accessorが不要な理由
  • 親子関係のテーブルの扱いかた

バリデーション

  • 自作
  • 組み合わせ
  • テーブルの親子関係

その他

  • 例外処理
  • ロールバックの動き
  • テーブル構築時の指定(not nullなど) 
  • データの流し込み作業

ざっと考えただけでもこれくらいある。

とりあえず、1つずつ吸収していくしかないですね。

 

お問い合わせフォームに関してはこれで完結とさせていただきます。

今後は疑問に思った事を中心に作業してみたいと思います。

 

以上、最後まで読んでいただきありがとうございます。

 

 

Ruby on Railsのお勉強 〜お問い合わせフォーム編(Validation) その6〜

はじめに

漸くバリデーションに入ります。

フレームワークを使用する上で避けては通る事のできない道です。

ドキュメントを読んでみたのですが、端折っている箇所があって理解に時間が掛かるので、今回は初歩的な使い方に注力します。

↓こちら参考にしたドキュメントになります。

Active Record バリデーション | Rails ガイド

 

今回やる事

  • モデルにバリデーションを指定
  • 確認画面(inquiry/confirm)でバリデーションを実行
  • エラーメッセージの表示
  • エラーメッセージの日本語化

 

モデルにバリデーションを指定

class Inquiry < ActiveRecord::Base
  # Validation
  # name ... 2文字以上〜30文字以下
  # mali ... 未入力不可、255文字以下
  # mail_confirmation ... mailの入力確認
  # telephone ... 数字のみ
  validates :name, length: { in: 2..30 }
  validates :mail, confirmation: true, length: {maximum: 255}
  validates :mail_confirmation, presence: true
  validates :telephone, format: { with: /\A[0-9]+\z/ }

  def init(inq_params)
    @name = inq_params[:name]
    @mail = inq_params[:mail]
    @mail_confirmation = inq_params[:mail_confirmation]
    @telephone = inq_params[:telephone]
  end
end

 

確認画面(inquiry/confirm)でバリデーションを実行

class InquiryController < ApplicationController
  def index
    @inquiry = Inquiry.new(post_params)
  end

  def confirm
    @inquiry = Inquiry.new(post_params)
    if @inquiry.valid? == false
      logger.debug @inquiry.errors.messages
      render template: 'inquiry/index'
    end
  end

  def thanks
  end

  private
    def post_params
      if params.has_key?(:inquiry)
        params.require(:inquiry).permit(
          :name,
          :mail,
          :mail_confirmation,
          :telephone
        )
      else
        {}
      end
    end
end

 

エラーメッセージの表示

<h1>お問い合わせ入力フォーム(Inquiry#index)</h1>
<p>Find me in app/views/inquiry/index.html.erb</p>
<div>
  <!--
  例外発生時
  -->
  <% if @inquiry.errors.any? %>
    <div id="error_explanation">
      <h2>入力項目を確認してください。</h2>
      <ul>
      <% @inquiry.errors.full_messages.each do |msg| %>
        <li><%= msg %></li>
      <% end %>
      </ul>
    </div>
  <% end %>
  ... 中略 ...
</div>

 

エラーメッセージの日本語化 

日本語化の手順はこちらを参考にして設定しております。ありがとうございます。

qiita.com

 

感想と課題

バリデーション自体の組み込み作業は難しくないと思います。

ただ、様々な状況を想定して使えるようになっているので全ての使用を把握するのが大変だと思います。

あと、エラーメッセージの差し替え方法と自作バリデーションはいつの日か必ず要求される事になるので予習しておきたい課題です。

 

ざっとですがバリデーションはこの辺にして、次回はいよいよDB書き込みに行きたいと思います。

 

以上、最後まで読んでいただきありがとうございます。

 

 

gitとGitHub連携の設定について

はじめに

gitの初期設定を行ったのでGitHubとの連携も設定してみたいと思います。

e-horoyoi.hatenablog.com

 下記の準備が必要ですが、こちらは既にあるものとして話を進めます。

 

手順

公開鍵をGitHubへ登録

  1. 右上の"+"からSettingを選択
  2. 開いた画面の左メニューから"SSH and GPG keys"を選択
  3. SSH keysの"New SSH key" ボタンを押下
  4. "title"、"Key"に公開鍵の情報を入力して"Add SSH key"を押下(注)

注:"title"にどの公開鍵か判別できるようにしましょう。

 

ローカル環境の設定

GitHubに公開鍵が登録できたらローカル環境(自身のホームディレクトリ)にてsshの設定を追加します。

設定ファイルの追加

>cd ~/

>vi ~/.ssh/config

Host github github.com
HostName github.com
IdentityFile ~/.ssh/{秘密鍵のファイル名}
User git

>chmod 0600 ~/.ssh/config

 

疎通の確認

>ssh -T github

下記が表示されればGitHubと鍵認証でやり取りできています。

"Hi {ユーザー名}! You've successfully authenticated, but GitHub does not provide shell access."

 

ローカルに作成中のソースをリポジトリへ登録

GitHub側でやる事

GitHubにログインしてリポジトリを作成します。

f:id:e-horoyoi:20170727095922p:plain

 

 ローカル環境でやる事 

Railsの話になってしまいますが、/log、/tmp、/vendorは管理する必要が無いので.gitignoreに登録しておきます。 

>git init
>git commit -m "first commit"
>git remote add origin git@github.com:{ユーザー名}/{リポジトリ名}.git # ssh_key設定ありの場合
>git remote add origin https://github.com/{ユーザー名}/{リポジトリ名}.git # ssh_key設定なし
>git push -u origin master

これで開発中のファイルをGitHubで管理できます。

 

以上、最後まで読んでいただきありがとうございます。

gitの設定を忘れてた...

はじめに

『やろう、やろう』と思っていて忘れていました。

今までの作業も個人でやっているだけなので特に管理する意識もありませんでした...

良くないと思いGitの設定をやる事にしました。

開発環境構築後に毎回やる事なので書いておきます。

 

開発環境

OS: CentOS7

git: 1.8.3.1

 

初期設定

とりあえず、初期設定は下記ぐらいしかいつもやっておりません。

詳しい内容はGit - Git の設定で確認できます。

git config --global user.name "ユーザー名"
git config --global user.email "メールアドレス"
git config --global core.editor vim # commit時に使用するエディタの指定
git config --global color.ui true # 色付け
git config --global core.autocrlf input # 改行コード対策(CRLFとかLFとか)

 

エイリアス

頻繁に使用するコマンドはエイリアスを設定しておきます。

詳しい内容はGit - Git エイリアスで確認できます。

git config --global alias.st status
git config --global alias.cl clone
git config --global alias.br branch
git config --global alias.co checkout
git config --global alias.ci commit

 

以上、読んでいただきありがとうございます。