Laravel Migrationen schöne Möglichkeit der Deaktivierung von foreign key checks

Beim laufen laravel Migrationen, ich bin vor eine kleine Unannehmlichkeit. Ich benutze Laravel 5.1.

Da gibt es eine Menge von Tabellen mit vielen Beziehungen, ist es wahrscheinlich unmöglich, dass ich benennen Sie die migration-Dateien so führen Sie in der richtigen Reihenfolge, so dass keine foreign key-Einschränkung verletzt wird. Das war, was ich Tat, nachdem in der Vergangenheit, und es war sehr inpractical.

Was ich jetzt mache, ist die Definition jeder migration so:

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

Das problem mit diesem ist, dass es mühsam zu schreiben und es clutters den code.

Habe ich auch gedacht, über das erstellen von zwei dummy-migration-Dateien, deren einziger Zweck es wäre, aktivieren und deaktivieren Sie die foreign key checks, und ich nannte Sie so, dass Sie am Anfang und am Ende jeder migration.

Wenn es eine elegante Lösung, wäre es möglich anwenden, um die seeding-Prozess als gut, da dies eher ein problem als gut.

Dies ist natürlich eine sehr improvisierte Lösung, und ich Frage, ob es einen besseren Weg, es zu tun. Gibt es einige beforeMigrate und afterMigrate Methoden, die ich überschreiben kann, oder etwas entlang jenen Linien?

Ist und wenn nicht, wie gehen Sie es tun?

Alle Erkenntnisse wäre zu begrüßen, ich mag alle Optionen, die ich festgestellt habe.

  • Sie sollten immer führen Sie in der richtigen Reihenfolge, wenn Sie handwerklich zu erstellen Migrations-und Sie haben den richtigen Zeitstempel. Sie laufen in der Reihenfolge der timestamps..
  • Ja, das ist es, was ich meinte, als bezeichnet wird die Datei um. Das Problem ist, manchmal nicht, erzeugen Sie in der richtigen Reihenfolge, oder manchmal, Sie könnten eine zyklische Abhängigkeit, d.h. beide Tabellen Fremdschlüssel auf einander beziehen. Egal, in welcher Reihenfolge Sie ausgeführt, dass beispielsweise, erhalten Sie eine foreign key-constraint-Verletzung, es sei denn, Sie deaktivieren die Prüfungen.
  • Der beste Weg, diese Problematik zu vermeiden ist, schafft eine migration mit der Erstellung der Tabelle die erste und dann noch eine, die erstellt/löscht Schlüssel.
  • Nicht besonders, aber Sie können deaktivieren Sie die foreign key checks auch so: \DB::getSchemaBuilder()->disableForeignKeyConstraints(). Nicht sicher, ob es einen besseren Weg, um diese Methode aufrufen.
  • Ich habe genau das gleiche problem wieder, mit noch einem anderen Projekt. Als einen temporären hack mache ich genau so, wie vorgeschlagen, in den OP; 2 dummy-migration-Dateien mit Zeitstempel versehene ausführen, bevor und nachdem alles andere, drehen foreign key checks auf und ab beziehungsweise. Es ist meine überzeugung, dass Laravel migration system ist grundlegend falsch. Überprüfung der Erstellung der Tabelle code-split zwischen all diesen Dateien ist hässlich und inconvienient. Von nun an ich werde bleiben, alles in einer einzigen migration-Datei, mit foreign key checks deaktiviert und aktiviert am Anfang und Ende, und alle schema Logik-übersichtlich angeordnet-zwischen.
InformationsquelleAutor Pavlin | 2015-12-15
  1. 27

    Hatte ich eine ähnliche Aufgabe bei der hand, wenn Lumen /Laravel begonnen, mit Pass, und ich hatte zu Graben der früheren oauth-server-Implementierung von lucadegasperi/oauth2-server-laravel.

    Habe ich es endlich geschafft, die Dinge durch die Schaffung von 2-Migrationen, von denen der erste löscht foreign keys und die zweite löscht tatsächlich den Tischen.

    Musste ich Daten vor der Migration von Laravel ist Pass (2016-06-01), damit Sie ausgeführt werden, bevor diese.

    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();
    }
    //...
}

    Und in der zweiten Datei
    2016_05_31_000001_clear_old_oauth.php

    //...
public function up()
{
    Schema::disableForeignKeyConstraints();
    Schema::drop('oauth_access_tokens');
    //...
    Schema::enableForeignKeyConstraints();
}
//...
    • Das ist wirklich schön! Hat dieses erst seit kurzem, oder war es in laravel für eine Weile und ich es nicht bemerkt, wenn ich dieses problem gehabt?
    • Hi @Pavlin, ich weiß nicht, Wann dieser Hinzugefügt wurde, in Laravel / Lumen. Beachten Sie, dass Sie brauchen, um die Namen der foreign key-Einschränkungen in zB. PhpMyAdmin (Struktur -> Beziehungen)
    • Dies wurde Hinzugefügt, um Laravel seit version 5.2
    InformationsquelleAutor 4levels
  2. 3

    Ich habe dies getan, indem er die foreign key-Logik in eine separate migration-Datei. Dies verhalf mir zu:

    • Deaktivieren Sie die foreign key-Einschränkungen.
    • Sicher löschen Sie die Datenbank, wenn es vorhanden ist.

    Code:

    //file: 2017_06_19_230601_fk_postuser_table.php

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

    Andere wichtige Aspekt zu erinnern ist, um Tropfen der foreignKey ZUERST, dann die Spalte. Abwurf der ersten Spalte den Fehler auslöst:

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

    Die richtige Reihenfolge ist wichtig:

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

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

    Manchmal der beste Weg zu gehen über diese ist immer, drop erstellt Fremdschlüssel in Ihre rollback-migration-code.

    Lassen Sie uns sagen, Sie haben ein foreign key in Ihrem up schema wie folgt:

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

    In Ihrem down migration, sollten Sie

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