您好,登錄后才能下訂單哦!
今天就跟大家聊聊有關怎么在Laravel項目共用migrations,可能很多人都不太了解,為了讓大家更加了解,小編給大家總結了以下內容,希望大家根據這篇文章可以有所收獲。
在各項目里建各自 migration
我們先在 web/API 和 admin 里都建各自的 migration:
## web 目錄 php artisan make:migration foo # Created Migration: 2018_09_19_144940_foo php artisan migrate # Migration table created successfully. # Migrating: 2018_09_19_144940_foo # Migrated: 2018_09_19_144940_foo php artisan migrate:status # +------+-----------------------+-------+ # | Ran? | Migration | Batch | # +------+-----------------------+-------+ # | Yes | 2018_09_19_144940_foo | 1 | # +------+-----------------------+-------+ ## admin 目錄 php artisan make:migration bar # Created Migration: 2018_09_19_145255_bar php artisan migrate # Migrating: 2018_09_19_145255_bar # Migrated: 2018_09_19_145255_bar php artisan migrate:status # +------+-----------------------+-------+ # | Ran? | Migration | Batch | # +------+-----------------------+-------+ # | Yes | 2018_09_19_144940_foo | 1 | # +------+-----------------------+-------+ # | Yes | 2018_09_19_145255_bar | 2 | # +------+-----------------------+-------+
從 artisan migrate:status 的結果來看,兩個 migration 都正常執行了,接下來我們試一下回滾操作。
先直接在 web 目錄執行
php artisan migrate:rollback # Migration not found: 2018_09_19_145255_bar
報錯了,因為在 web 項目里找不到 bar 這個 migration 文件;那如果我們剛剛是直接在 admin 目錄執行,是能夠正常回滾的,但是如果我們指定回滾兩個版本:
php artisan migrate:rollback --step=2 # Migration not found: 2018_09_19_144940_foo # Rolling back: 2018_09_19_145255_bar # Rolled back: 2018_09_19_145255_bar
這次回滾操作也是有問題的,只回滾了一半。
所以我們應該按照 migrate 的相反順序執行回滾,即先在 admin 執行一次,然后再到 web 里再執行一次。我們上面的實驗很簡單,要記住這些順序也不難,可是在實際的項目中,你的 migrations 就比這個復雜多了,而且只通過 migrate:status 你也看不出來執行順序到底是怎么樣的,所以在各個項目里各自維護各自的 migrations 似乎行不通...
共用一份 migration
上面的實驗我們可以知道,我們在執行 artisan migrate 的時候,Laravel 會讀取 migrations 目錄里的文件和數據庫里的記錄,然后再執行相應的操作(并記錄這次操作);回滾的時候 Laravel 會讀取數據庫中的記錄,然后執行 migrations 目錄里相應的文件中的 down 方法。
而當 migrations 分散在不同的項目(目錄)里的時候,不管你在哪個項目中執行 migrate:rollback
時,都可能只有一部分 migration 文件被加載進來,因此會造成一些奇奇怪怪的問題。
那我們可以將所有 migrations 放在同一個地方,怎么操作呢?再建一個新的項目似乎有點麻煩了...我們先看看幫助吧:
php artisan migrate --help Description: Run the database migrations Usage: migrate [options] Options: --database[=DATABASE] The database connection to use --force Force the operation to run when in production --path[=PATH] The path to the migrations files to be executed --realpath Indicate any provided migration file paths are pre-resolved absolute paths --pretend Dump the SQL queries that would be run --seed Indicates if the seed task should be re-run --step Force the migrations to be run so they can be rolled back individually -h, --help Display this help message -q, --quiet Do not output any message -V, --version Display this application version --ansi Force ANSI output --no-ansi Disable ANSI output -n, --no-interaction Do not ask any interactive question --env[=ENV] The environment the command should run under -v|vv|vvv, --verbose Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug
果然有我們想要的東西:--path 和 --realpath,先來看看這兩個參數是什么用途:
--path[=PATH] 指定 migrations 文件的路徑
--realpath 表示 --path 指定的路徑為絕對路徑
那我們在進行 migrations 操作的時候,指定同一個路徑,那就可以共用 migrations 了:
php artisan make:migration foo --path="../admin/database/migrations" # or php artisan make:migration foo --path="/the/absolute_path/to/admin/database/migrations" --realpath # migrate php artisan migrate --path="../admin/database/migrations" # migrate:rollback php artisan migrate:rollback --path="../admin/database/migrations"
注:當你不帶 --realpath 的時候,path 是以項目的根目錄為 / 的
總結
所以,當我們需要在多個 Laravel 項目中共用 migrations 的時候,最好的做法是通過 --path 指定 migrations 文件的目錄,這個目錄可以是一個獨立的 git repo,也可以是其中一個 Laravel 項目(我個人推薦放在其中一個項目中,采用獨立的 git 分支),這樣既可以共用 migrations,在團隊協作的時候也不會混亂和出現沖突
看完上述內容,你們對怎么在Laravel項目共用migrations有進一步的了解嗎?如果還想了解更多知識或者相關內容,請關注億速云行業資訊頻道,感謝大家的支持。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。