ginza.rb 第0回を開催して Rails 4.0 のリリースノートを読んだ

先月にginza.rb 第0回を開催しました。ちょっと遅れましたがやった内容などを書きます。

やったこと

Ruby on Rails 4.0 Release Notesを頭から一通りざっくり読んで、Rails 4.0 の新機能と変更点を勉強しました。

まず、4.0 での大きな追加項目なはずの

• Strong Parameters
• Turbolinks
• Russian Doll Caching

についてはなぜか冒頭に名前が書かれているだけで、機能の説明がありません。なので下記のサイトを見つつざっくりどんな機能なのかを説明しました。

• Rails4.0に含まれる strong_parameters について - willnet.in
• Rails 4.0 に入る予定の turbolinks について調べた - willnet.in
• #387 Cache Digests - RailsCasts

残りは普通に Release Notes を読んで、少し時間が余ったので「3 Major Features」のマインドマップを眺めながら、Release Notes に載っていない機能や削除されてしまった機能について話したりしました。以下は個人的に気になったところのまとめです。

SQL_MODE=STRICT_ALL_TABLES

mysql and mysql2 connections will set SQL_MODE=STRICT_ALL_TABLES by default to avoid silent data loss. This can be disabled by specifying strict: false in your database.yml.

SQL_MODE=STRICT_ALL_TABLES ってなに？となったので調べました。簡単にまとめると、想定外のデータが入ったときにMySQL側で空気読んでよしなにしてくれていたのを止めさせるための設定です。

個人的に助かるなーと思ったのは、string で設定したカラムに256文字以上の文字列を入れて保存した時。これまでは普通に(エラーとか出ずに)保存されるけど255文字以降は切り捨て、という挙動だったのが、ちゃんとエラーを出してくれるようになります。そもそもカラムに validation をしっかり定義しておけば問題ない話なのですが…＞＜。これからはうっかり忘れてもすぐに気付けそうですね。

詳しくは下記の記事を参照のこと。

• これだけは覚えておきたい!!MySQL の６つの自動変換 - sakaikの日々雑感～(T)編
• 勝手に補足 - これだけは覚えておきたい!!MySQL の６つの自動変換 | キムラデービーブログ
• MySQLの自動変換を丁重にお断りするためのたった１種類の呪文 - sakaikの日々雑感～(T)編

Remove automatic execution of EXPLAIN queries

Remove automatic execution of EXPLAIN queries. The option active_record.auto_explain_threshold_in_seconds is no longer used and should be removed.

あまり使われなかったため削除されてしまったようです。僕も追加された当時は、この機能べんりかも！！と思ってたのですが…結局使わず仕舞いでした。

remove config.auto_explain_threshold_in_seconds by senny · Pull Request #9400 · rails/rails

migration

個人的に一番気になったのはここ。

Active Record Migrations — Ruby on Rails Guides によると、下記のように、rollback の仕方が推測できない処理を reversible メソッド中のブロックで定義することで、up と down を使わずとも change だけで migration を実装できるようになったとのこと。

class ChangeProductsPrice < ActiveRecord::Migration
  def change
    reversible do |dir|
      change_table :products do |t|
        dir.up   { t.change :price, :string }
        dir.down { t.change :price, :integer }
      end
    end
  end
end

上記のコード見ただけだと、up と down を使った方が綺麗に書けるように思えます。ginza.rb のときは「なんでこんなの追加されたんだろう…」と思っていました。しかしRailsGuides をちゃんと読むとメリットがあることが分かります。

例えば下記のような複雑な migration の定義を up と down に分けて書くのはかなり面倒でしょう。また、「change で定義した場合に rollback すると、通常の逆順で切り戻してくれる」というのも便利です。下記の例で rollback すると

1. email_address から email へのリネーム
2. home_page_url カラムの削除
3. reversible の down に渡したブロックを実行
4. products テーブルを削除

の順で実行されます。

 def change
    create_table :products do |t|
      t.references :category
    end

    reversible do |dir|
      dir.up do
        #add a foreign key
        execute <<-SQL
          ALTER TABLE products
            ADD CONSTRAINT fk_products_categories
            FOREIGN KEY (category_id)
            REFERENCES categories(id)
        SQL
      end
      dir.down do
        execute <<-SQL
          ALTER TABLE products
            DROP FOREIGN KEY fk_products_categories
        SQL
      end
    end

    add_column :users, :home_page_url, :string
    rename_column :users, :email, :email_address
  end

実行順序にも気を使わなくてはいけないケースでは、upとdownではかなり面倒くさそうですね。これらの点を考えると reversible もなかなか便利に使えるケースがありそうです。

gems

ginza.rb の中で話に上がった gemです。

• kzk/unicorn-worker-killer
  • 監視用のプロセスをたてることなく、Unicorn のメモリを監視して再起動できる
• livingsocial/rake-pipeline
  • rake タスクをフィルタのように重ねて出力を得るような gem らしい
• rails-api/active_model_serializers
  • モデルを json に変換するための gem。jbuilder と rabl の使い分けに悩みますね

次回

次回は2013年7月16日(火)です。strong_parameters のソースコードを読みます。残席わずかですが宜しければ是非！

Ginza.rb 第1回 strong parameters - Ginza.rb