在进行laravel迁移时,我面临一些小小的不便.我使用Laravel 5.1.
由于存在许多具有许多关系的表,因此我可能无法重命名迁移文件,因此它们以正确的顺序运行,因此不会违反外键约束.这就是我过去做过的事情,而且非常不实用.
我现在正在做的是定义每个迁移,如下所示:
class CreateSomeTable extends Migration { public function up() { DB::statement('SET FOREIGN_KEY_CHECKS=0;'); // my table definitions go here DB::statement('SET FOREIGN_KEY_CHECKS=1;'); } public function down() { DB::statement('SET FOREIGN_KEY_CHECKS=0;'); // drop table DB::statement('SET FOREIGN_KEY_CHECKS=1;'); } }
这样做的问题在于它编写起来很繁琐,并且使代码变得混乱.
我还考虑过创建两个虚拟迁移文件,其唯一目的是启用和禁用外键检查,我会以这样的方式命名它们,它们将在每次迁移的开始和结束时运行.
如果有一个优雅的解决方案,也可以将它应用于播种过程,因为这也是一个问题.
这显然是一个非常即兴的解决方案,我想问是否有更好的方法.有一些beforeMigrate
和afterMigrate
我可以覆盖的方法或类似的规定?
如果没有,你怎么去做呢?
任何见解都会受到赞赏,我不喜欢我所说的所有选项.
当Lumen/Laravel开始使用Passport时,我有一个类似的任务,我不得不放弃lucadegasperi/oauth2-server-laravel之前的oauth服务器实现.
我终于设法通过创建2个迁移来实现目标,其中第一个清除外键,第二个实际删除表.
我必须在Laravel's Passport(2016-06-01)的迁移之前使用日期,所以它们将在那之前执行.
2016_05_31_000000_clear_old_oauth_relations.php
//... class ClearOldOauthRelations extends Migration { public function up() { Schema::disableForeignKeyConstraints(); // drop foreign keys Schema::table('oauth_access_tokens', function (BluePrint $table) { $table->dropForeign('oauth_access_tokens_session_id_foreign'); }); //... Schema::enableForeignKeyConstraints(); } //... }
并在第二个文件中
2016_05_31_000001_clear_old_oauth.php
//... public function up() { Schema::disableForeignKeyConstraints(); Schema::drop('oauth_access_tokens'); //... Schema::enableForeignKeyConstraints(); } //...