web-dev-qa-db-ja.com

Laravel migrations外部キーチェックを無効にする良い方法

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;');
    }
}

これの問題は、書くのが面倒で、コードが煩雑になることです。

また、2つのダミーの移行ファイルを作成することも考えましたが、その目的は外部キーチェックを有効または無効にすることだけであり、各移行の開始時と終了時に実行されるように名前を付けます。

洗練された解決策がある場合、それも播種プロセスに適用することが可能でしょうか？これはそこでも問題になる傾向があるからです。

これは明らかに非常に即興的な解決策であり、それを行うより良い方法があるかどうかを尋ねています。オーバーライドできるbeforeMigrateメソッドとafterMigrateメソッド、またはそれらの行に沿ったものはありますか？

そうでない場合、どのようにそれを行うのですか？

どんな洞察も歓迎されます、私は述べたすべてのオプションを嫌います。

phplaravelmigration
25
Pavlin

Lumen/Laravel= Passportの使用を開始し、以前のoauthサーバー実装を lucadegasperi/oauth2 -server-laravel 。

私は最終的に2つの移行を作成して物事を進めることができました。最初の移行は外部キーをクリアし、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();
    }
    //...
}

2番目のファイル2016_05_31_000001_clear_old_oauth.php

//...
public function up()
{
    Schema::disableForeignKeyConstraints();
    Schema::drop('oauth_access_tokens');
    //...
    Schema::enableForeignKeyConstraints();
}
//...
32
4levels

これを行うには、外部キーロジックを別の移行ファイルに抽出します。これは私を助けました：

  • 外部キー制約を無効にします。
  • データベースが存在する場合、安全に削除します。

コード内：

//file: 2017_06_19_230601_fk_postuser_table.php

public function down()
{
        Schema::disableForeignKeyConstraints();
        Schema::dropIfExists('post_user');
}
3
Recep Can

覚えておくべきもう1つの重要な側面は、foreignKeyを最初にドロップし、次に列をドロップすることです。最初に列をドロップすると、エラーがスローされます。

Cannot drop index 'tableName_columnName_foreign': needed in a foreign key constraint

適切な順序が重要です：

    public function down()
    {
        Schema::table('tableName', function (Blueprint $table) {
            $table->dropForeign(['columnName']); // fk first

            $table->dropColumn('columnName'); // then column
        });
    }
0
cmeza

これを実行する最善の方法は、作成された外部キーをロールバック移行コードに常にドロップすることです。

次のようにupスキーマに外部キーがあるとします。

Schema::table('mytable', function (Blueprint $table) {
    $table->foreign(mycolumn)->references('id')->on(foreigntable);
}

down移行では、次のものが必要です。

$table->dropForeign(mytable_mycolumn_foreign);//this is how laravel generates the foreign keys
0
Chibueze Opata