Rails: 2006年10月アーカイブ

Migrationで初期データ作成

Migrationその１の続き

Migrationで初期データの用意も出来ます。
開発時のユーザーデータとか、コードテーブルのようなマスタ定義を書いておくと、
複数人で開発するときに激しく便利。

$ ruby script/generate migrate insert_users

002_insert_usersというファイルが出来ているので、
テキストエディタで編集。

class InsertUsers < ActiveRecord::Migration
  def self.up
     User.create(:name=>"本田 忠勝"   , 
                 :password => "蜻蛉切り",
                 :birth => "1548-01-01",
                 :roll => "徳川四天王",
                 :time_stamp => Time.now
                 )
     User.create(:name=>"酒井忠次"   , 
                 :password => "東三河",
                 :birth => "1527-01-01",
                 :roll => "徳川四天王",
                 :time_stamp => Time.now
                 )
     User.create(:name=>"榊原康政"   , 
                 :password => "無",
                 :birth => "1548-01-01",
                 :roll => "徳川四天王",
                 :time_stamp => Time.now
                 )
     User.create(:name=>"井伊直政"   , 
                 :password => "赤備え",
                 :birth => "1561-01-01",
                 :roll => "徳川四天王",
                 :time_stamp => Time.now
                 )
  end
  def self.down
    @users = User.find_by_roll('徳川四天王')
    @ users.destroy
  end
end

すでにusersのmodelが出来ているはずなので、
User.createでレコードを生成出来ます。

self.downにはfind_by_XXXで検索してdestroyしてやれば良いでしょう。

Migrationで書き方あれこれ

初め迷ったのが、「Migrationで複数のテーブルを作る場合、一つのファイルに纏めるべきか？」と言う点です。
分けて書いても、一つに纏めても変わらないのですが、個人的には分けた方が良いと思います。
理由は単純でコードが見やすいからです。

例えば６テーブルMigrationで書いた場合、rake migrateした時にいきなりバージョンが6になるか１になるかの違いしかありませんし。

もう一つは、データはMigrationで用意すべきかfixtureで用意すべきか？
どっちでもいい気がします。マスタデータの様なモノはMigrationで、それ以外はお好きなほうで。
YAMLのほうが編集はしやすいですが、本来はユニットテスト用なので、微妙な所です。

ターミナルからのfixtureのロードの仕方は・・・忘れたので後で書いておきます。

Migration

最近Railsで開発していて、migrationを使い初めてみた。 （以前Rails使っていた頃は無かった気がする・・・）

激しく便利。軽くメモ代わりに。

データベースの定義（DDL）をRails側で実装出来る機能ですが何が嬉しいかといえば、

• DDLをバージョン管理できる
• いつでも任意のバージョンに戻す事ができる
• modelさえ作ってしまえばテストデータをrubyで書いてinsertできる

チーム開発にはもってこいの機能です。

使い方

生成はscript/generateで。 ありがちなusersというテーブルを生成。

$ ruby script/generate migrate  create_users

こうすると、”001_create_users.rb”というファイルがdb/migrateに出来ているので、
テキストエディタで定義を編集。

self.upとself.downというメソッドがあるので、
self.upはバージョンアップ時に実行され、
self.downはダウングレード時に実行されるのね。

class CreateUsers < ActiveRecord::Migration
  def self.up
      options = {
        :options     => "ENGINE=innodb DEFAULT CHARSET=utf8"
      }
      create_table(:users, options) {|table|
        table.column :name,                 :integer
        table.column :password,             :string, limt => 50
        table.column :birth,                :date
        table.column :roll,                 :integer
        table.column :time_stamp,           :datetime
      }
  end
  def self.down
    drop_table : users 
  end
end

基本的にupにテーブル定義、
downにdrop_tableしておけばよい。

実際に動かしてみる。

$ rake migrate

これで、DBにusersテーブルが出来ているハズ。

逆にダウングレードする場合は

$ rake migrate　VERSION=[バージョン番号]

としてあげればOK。
バージョンってのは、generateしたときに振られる　"001"とかの連番。

スキーマ命令

スキーマ定義に使える命令をメモ代わりに

• create_table(name, options) テーブルを作成する。
• drop_table(name) テーブルを削除する。
• add_column(table_name, column_name, type, options) カラムを追加する。
• rename_column(table_name, column_name, new_column_name) カラム名の変更
• change_column(table_name, column_name, type, options) カラム属性の変更
• remove_column(table_name, column_name) カラムの削除
• add_index(table_name, column_name): インデックスを追加する。
• remove_index(table_name, column_name): インデックスを削除する。

定義に使える型

今のところ、PostgreSQLとMySQLのみ対応らしい。

抽象表現	rubyでの型	PostgreSQL	MySQL
:primary_key	Fixnum	serial primary key	int(11) DEFAULT NULL auto_increment PRIMARY KEY
:string	String	character varying(255)	varchar(255)
:text	String	text	text
:integer	Fixnum	integer	int(11)
:float	Float	float	float
:datetime	Time	timestamp	datetime
:timestamp	Time	timestamp	datetime
:time	Time	timestamp	datetime
:date	Date	date	date
:binary	String	bytea	blob
:boolean	Object	boolean	tinyint(1)

ActiveRecord上でrubyでの型とDBの型で不具合が起こるとすれば、
decimal型のマッピングがFloatクラスにされる事で、演算を繰り返すと丸め誤差が生じる事。
migrationを使っていればその心配はない。

今日はこの辺りまで。