不知道你有沒有把數(shù)據(jù)遷移寫入Migration文件的經(jīng)歷，相信無論是老鳥還是新手都這樣干過吧。事實上，這樣做并不是行不通，只不過這樣的實踐慢慢會給你引入一些不必要的麻煩。
一般認(rèn)為db/migrate文件夾里的內(nèi)容是關(guān)于你數(shù)據(jù)庫Schema的演變過程，每個新的開發(fā)或線上環(huán)境都要通過這些Migration來構(gòu)建可用的數(shù)據(jù)庫。但如果這里裝入了，負(fù)責(zé)細(xì)節(jié)的業(yè)務(wù)代碼，比如一些歷史遺留數(shù)據(jù)的遷移代碼之類的，當(dāng)一段時間后，數(shù)據(jù)庫的結(jié)構(gòu)變化了，但Migration沒有跟著變化，漸漸的曾經(jīng)的輔助代碼，就成了垃圾代碼，不僅不能幫忙構(gòu)建環(huán)境，還會讓rake db:migrate的執(zhí)行過程異常中斷，無形中增加了新環(huán)境的構(gòu)建成本。
所以正確的做法應(yīng)該是，Migration只負(fù)責(zé)Schema相關(guān)的事宜，而不該過問數(shù)據(jù)的細(xì)節(jié)，具體的數(shù)據(jù)細(xì)節(jié)，全部交由rake任務(wù)來做，并且這些rake任務(wù)也不是一成不變的，隨著時間的推移它們也會廢棄掉，但因為它們與系統(tǒng)的其它部分不想管，所以直接刪掉即可。不過使用Rake做數(shù)據(jù)遷移也是有講究的，具體如下:
Bad Rake Task
|
1
2
3
4
5
6
7
8
9
10
11
|
# lib/tasks/temporary/users.rakenamespace :users do task :set_newsletter => :environment do User.all.each do |user| if user.confirmed? user.receive_newsletter = true user.save end end endend |
任務(wù)會遍歷所有用戶，想想如果數(shù)據(jù)集很大會怎樣
通過ActiveRecord更新數(shù)據(jù)，會觸發(fā)模型中的驗證和創(chuàng)建回調(diào)方法
通過if條件語句來判斷是否需要更新數(shù)據(jù)
不能直觀的看出這個任務(wù)是干什么的，沒有一個desc，所以也無法通過rake -T找到它
Good Rake Task
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
# lib/tasks/temporary/users.rakenamespace :users do desc "Update confirmed users to receive newsletter" task set_newsletter: :environment do users = User.confirmed puts "Going to update #{users.count} users" ActiveRecord::Base.transaction do users.each do |user| user.mark_newsletter_received! print "." end end puts " All done now!" endend |
通過desc我們可以清楚的知道任務(wù)的意圖，并且它也會顯示在rake -T中
通過scope解決了if語句的問題
引入了計數(shù)器，以及執(zhí)行狀態(tài)顯示，能讓我們了解到程序運行時的情況
把數(shù)據(jù)的更改放到了事務(wù)中執(zhí)行，可以語法因為數(shù)據(jù)異常，奔潰導(dǎo)致的不一致問題
最后要補充說明的一點是，有時候，可能直接用SQL語句更簡單有效，特別是在數(shù)據(jù)集比較大的情況下，一條SQL能幫你省去不少無謂的循環(huán)！另外，記得上開發(fā)環(huán)境之前，最好預(yù)先檢測一下Rake任務(wù)的有效性。
