config.active_record.schema_format

データベースにviewとかtriggerとかインデックスの文字数制とか、Railsのruby-dsl形式の schema が対応してくれない設定をしていて、テストに失敗するときは！

# config/enviroment.rb
  # Use SQL instead of Active Record's schema dumper when creating the test database.
  # This is necessary if your schema can't be completely dumped by the schema dumper,
  # like if you have constraints or database-specific column types
  # config.active_record.schema_format = :sql
  config.active_record.schema_format = :sql

ひーこんなオプションがあったなんて。enviroment のところにコメント付きで書かれてた。あははは。先日のRails勉強会、AMDDセッションで聞いた時には誰も知らないみたいだったんだけど。
[Rails]インデックスの文字数制限もSchemaDumpできるようにするも、いらないっぽい。

Agile Model Driven Development with Rails

Rails勉強会でtakaiさんのセッション聞いた。AMDDの概要はだいたい- データベースの進化的設計のかんじで。スキーマをバージョン管理して移行をスクリプト（自動）化しよう、開発用と本番用とか環境毎に違うバージョンのデータベースで動かそう、そうすればデータベース設計の変更は怖くない、というお話。
with Rails の部分は、 migration をきちんと書きましょう、Railsはmigration（データベース設計のバージョン管理）や、production,development,testの環境の分離とかをフレームワークに取り込んであるところがカコイイ（・∀・）という話でした。

確かに、僕がPHPから初めてRailsさわったときに、一番感動したのがこの部分です。あとRailsで足りないのは…

• 本番のデータを開発環境にコピーしてくれるツール（mysqldumpでも可能だけど。毎回全部とってくると重くなるから差分だけとか取り出せるとうれしい。ちなみに現在はプロジェクト毎に自作）
• 「リポジトリのDB」と「開発環境のDB」の違いからmigrationを自動生成してくれるツール（mysqldiff みたいなの。ついついphpMyAdminで構造変更とかしてしまうしー。それをmigrationに落とし込むのめんどい）
  • ついでにfixtureも書き直してくれる
• マイグレーションのテストってどうやるの？（今は rake migrate RAILS_ENV=test とか。でも rake migrate:test みたいにできて、現状コピー→migration とかをしてくれるとうれしい…）
• あとデータベースのバックアップね
• マーチンふぁうらー先生は「データベース設計の移行期間を設けて、その期間の間はどちらの構造でも動くようにしろ！」とか言うけど、それってかなり大変…Rails規模の開発ならいらないよね、と日和ったところも（汗）