Rails學習筆記：名字與migrations
下面是Yuan在學習Rails 2.3的時候總結的學習筆記，與大家分享。
Rails學習筆記1、名字：以下描述適用于rails2.1之后的版本
文件名就是個普通的ruby文件名前面加上時間戳，類名的命名規(guī)則跟普通的ruby類沒什么兩樣，只是要把前面的時間戳去掉，比如文件名為20080906120001_add_details_to_products.rb的migration類名應該是AddDetailsToProducts。
rails只把時間戳部分作為識別migration的id，所有執(zhí)行過的migration的id都將被保存到數(shù)據(jù)庫的schema_migrations表中。在rails2.1之前的版本中，migration的id是從1開始增長，但是，很容易想到，在多人合作開發(fā)項目的時候，這樣會很有問題。
當然，在新版本的rails中也可以通過在environment.rb設置config.active_record.timestamped_migrations的值為false來使用舊的方式生成migration的id。
（還是直接copy起來爽快……）
引用
The combination of timestamps and recording which migrations have been run allows Rails to handle common situations that occur with multiple developers.
For example Alice adds migrations 20080906120000 and 20080906123000 and Bob adds 20080906124500 and runs it. Alice finishes her changes and checks in her migrations and Bob pulls down the latest changes. Rails knows that it has not run Alice’s two migrations so rake db:migrate would run them (even though Bob’s migration with a later timestamp has been run), and similarly migrating down would not run their down methods.
Rails學習筆記2、修改migrations
如果寫錯了一個migration并且運行過，別直接修改它然后再次rake db:migrate，因為rails并不知道你修改了migration，執(zhí)行rake db:migrate時rails并不會做任何事。正確的做法是，先rake db:migrate:down或者rake db:rollback，然后再編輯這個migration，最后再次rake db:migrate。
一般來說最好不要去編輯一個已經(jīng)存在了的migration，即便里面有錯誤。
引用
you will be creating extra work for yourself and your co-workers and cause major headaches if the existing version of the migration has already been run on production machines.
最好的做法是寫一個新的migration來執(zhí)行修復上一個寫錯了的migration的操作。
引用
Editing a freshly generated migration that has not yet been committed to source control (or more generally which has not been propagated beyond your development machine) is relatively harmless. Just use some common sense.
Rails學習筆記3、創(chuàng)建migrations
generate model和generate scaffold命令都會創(chuàng)建一個migration，用于生成model對應的數(shù)據(jù)庫結構。如果想要執(zhí)行其它的修改數(shù)據(jù)庫結構的操作——比如說給某個表添加一個字段，可以用generate migration來手動創(chuàng)建一個migration。這3種創(chuàng)建migration的命令的格式都一樣：
- ruby script/generate scaffold|model|migration migration_name column_name:column_type ...
如果migration_name的名字格式是像“add_xxx_to_xxx”或者“remove_xxx_from_xxx”這樣的（經(jīng)試驗，也可以用駝峰命名法，像這樣:AddXXXToXXX），并且后面跟著字段名和類型列表，那么rails將自動把add_column和remove_column指令加到生成的migration代碼當中。例如：
ruby script/generate migration add_part_number_to_products part_number:string
將會生成：
- class AddPartNumberToProducts < ActiveRecord::Migration
- def self.up
- add_column :products, :part_number, :string
- end
- def self.down
- remove_column :products, :part_number
- end
- end
這樣的ruby代碼。
Rails學習筆記4、writing a migration
建表
- create_table :products do |t|
- t.string :name
- end
以上代碼將會創(chuàng)建一個名為products的表，其中包含一個名為name的字符類型字段。還有一種建表的方式是用bloc參數(shù)t的column方法，像這樣：Ruby代碼
- create_table :products do |t|
- t.column :name, :string
- end
引用
the first form(原文是second，我把代碼的順序調換了一下), the so called “sexy” migration, drops the somewhat redundant column method. Instead, the string, integer, etc. methods create a column of that type. Subsequent parameters are the same.
create_table方法默認會創(chuàng)建一個名為id的整型自增長字段作為主鍵（我還是比較喜歡uuid，google了一下，要使用uuid作為主鍵可參考：http://iceskysl.1sters.com/?action=show&id=349）。如果不想使用默認的id作為主鍵名稱，可以使用:primary_key來指定某一個字段為主鍵。如果要創(chuàng)建一個不帶主鍵的表(比如說一個多對多關聯(lián)的“中間表”就不需要主鍵)，可以傳遞一個hash :id=>false給create_table方法。
引用
The types supported by Active Record are :primary_key, :string, :text, :integer, :float, :decimal, :datetime, :timestamp, :time, :date, :binary, :boolean.
修改表結構
- change_table :products do |t|
- t.remove :description, :name
- t.string :part_number
- t.index :part_number
- t.rename :upccode, :upc_code
- end
以上代碼修改了products表結構，刪除了其中的description和name字段，添加了一個字符類型的part_number字段，并且給part_number字段添加索引，最后把upccode字段改名為upc_code。上面的代碼完成的事和以下代碼是一樣的：
- remove_column :products, :description
- remove_column :products, :name
- add_column :products, :part_number, :string
- add_index :products, :part_number
- rename_column :products, :upccode, :upc_code
引用
You don’t have to keep repeating the table name and it groups all the statements related to modifying one particular table. The individual transformation names are also shorter, for example remove_column becomes just remove and add_index becomes just index.
【相關閱讀】
