前言:
Migration實際上原本是要自己寫的，且這個遷移實際上跟字面上的語意差很多
Migration的作用是結構控管，也就是現在的資料庫使用的結構如果是共同協作，那麼如果我需要升級一個版本，那我統一丟一組migration給你就好了，你升級以後就能使用新寫出來的某某系統，大概是這樣的概念

(點選標題閱讀全文)




因此請注意以下幾點
1.實際上那些create database table是要自己寫的，drop只是剛好有這個功能恰好可以產生
2.這種東西無論利用drop來偷懶或是自己key都應該"只有一次"，絕非"我突然想要搬整個資料庫了然後所以我要開始重新從頭開始寫建資料庫的migration的up和down，重頭開始建資料庫，建立表格框架，最後import資料"，他的本意絕對不是拿來幹這種事情，如果你正在想上述事情，請務必採用速度最快且連產code都不用的sql dump，不要浪費時間在這上面
3.Migration的真正意義與好用的地方就是，如果雙方有共同的起始點(資料庫基底sql_dump起始版本之類的)，我們可以利用migration "以現在的資料庫為基底，如果建立一個新表格，調整一些欄位，就能使用改版完成的功能"





老實說他是分析Describe Table的結果，內容有點小問題...
不過至少對於SQL不行的還是丟PHP給他執行比較不會發生意外(吧

由於魔術方法會自己產生對應的down
如果generate migrate一個drop table，他的down會自動幫你產出該怎建回那個table

...說方便也還算方便，至少少打了一大堆字
不過根據測試結果來看，這跟原本的還是有一定的落差(主要是oil運作上的問題)

狀況1:
unsign沒有正確建構，需要自行調整
正確的FuelPHP用法大致如下(擷取自官網)
'id' => array('constraint' => 11, 'type' => 'int',
'auto_increment' => true, 'unsigned' => true),
不過你如果是用這個方法擷出來的，因為oil的小問題，內容會變成'type' => 'int unsigned'
如果要正式的解決，就乖乖的全域替換

不然如果想要加上限制，例如現在想要加上長度限制，我們來加個'constraint'=>100好了
然後你就會發現SQL報錯，原因是你會發現那條SQL變成 int unsigned(100)了

這裡有兩種解決方法:
1.正規到底，我們就分成三個參數個別指定
2.type強制設定，這裡直接打'type' => 'int(100) unsigned'是可以直接用的，看起來還比較乾淨


狀況2:
因為oil generate migratoin是利用DESCRIBE Table來解讀，並且產生相對應的創表碼
這裡就有另外一個小問題，DESCRIBE並沒有"comment"

尤其如果有習慣用comment來寫東西的就要注意了，這裡全部需要手動調整(嗯...如果誰很閒，去改generate讓他正常我也沒意見)


當然即使有這一堆狀況，他還是幫你把整個大架構畫出來了
既然狀況並不是很多，總比自己從0 key起好上太多
就當成一個免費拿架構出來修正的手段吧