2016-04-27 3 views
0

So lief die Anwendung gut auf Produktion und lokal. Dann habe ich lokal einige Änderungen an der DB vorgenommen, wie das Hinzufügen einer Spalte und das Ändern der Attribute einer Spalte. Als ich lokal migrieren ging, bekam ich einen Fehler, also löschte ich diese Migrationsdatei, rollte die gesamte Tabelle zurück und erstellte eine neue Migration mit allem, was ich wollte. Das lokal migriert und es funktioniert.Laravel Migration Local vs Produktion

Nun habe ich diese Änderungen auf github übertragen und sie werden automatisch zu Laravel Forge und auf den Produktionsserver gezogen. Ich bekomme eine Fehlermeldung, dass "Tabelle bereits existiert". Das github-Repository verfügt daher über eine neue Migration für diese eine Tabelle, die bereits auf meinem Produktionsserver ausgeführt wird.

Ich versuche herauszufinden, wie Sie dieses Problem beheben können, ohne die derzeit in der Produktions-DB-Tabelle vorhandenen Datensätze zu stören UND sicherzustellen, dass eine Migration stattfindet, falls ich die Tabelle löschen muss.

Danke!

+0

mehr hier lesen machen Dies ist ein der Fälle, in denen Sie wirklich die Wichtigkeit eines Staging/Produktions-Schatten-Servers erkennen :) – blackpla9ue

+0

Was ist "Production-Shadow"? –

+0

Hier können Sie eine Bereitstellung zuerst "inszenieren", bevor Sie sie auf dem Live-Server bereitstellen, um einige der Probleme bei der direkten Bereitstellung von Änderungen an einem Live-Server zu mindern. So wie dies. Insbesondere dort, wo mehrere Entwickler an einem einzelnen Projekt arbeiten und es Migrationsskripts gibt, ist es sehr praktisch. – blackpla9ue

Antwort

3

Wenn Sie neue Spalten hinzufügen oder etwas in einer Datenbank ändern möchten, die Produktion ist.

Sie müssen eine neue Migration erstellen, indem Sie diese Zeilen zur Datenbank hinzufügen. Es ist nicht so einfach, nur Ihre bestehende Migration zu ändern.

Der Grund, warum Sie "Tabelle ist bereits vorhanden" in der Produktion ist, liegt daran, dass die Migration bereits ausgeführt wurde.

Wenn Sie beispielsweise bereits eine Tabelle eines Benutzers migriert haben und entschieden haben, dass Sie der vorhandenen Tabelle einen Spitznamen hinzufügen möchten.

würden Sie eine neue Migration erstellen php artisan make:migration alter_users_table_add_nickname

und dann innerhalb dieser Migration insted Schema::create der Verwendung es würde die Verwendung von Schema::table

public function up() 
{ 
    Schema::table('users', function(Blueprint $table) 
    { 
     $table->string('nickname'); 
    }); 
} 

public function down() 
{ 
    Schema::table('users', function(Blueprint $table){ 
     $table->dropColumn('nickname'); 

    }); 
} 

Sie können auf Creating Columns

+0

Richtig, ich habe das abgedeckt. In diesem speziellen Fall hätte ich jedoch gefragt werden sollen, wie die neue Migrationsdatei in meinem Repository und die Datei auf dem Server abgestimmt werden sollen. Vielleicht ist es so einfach, den Produktionszweig mit meinem lokalen Zweig zu synchronisieren, damit diese Dateien die gleichen sind. –

+0

Nun, eine schnelle Lösung wäre, den Inhalt Ihrer Produktions-DB nicht die Struktur zu exportieren. Löschen Sie die Tabellen und führen Sie die Implementierung nach der Fälschung aus, um die Migrationen mit der bearbeiteten Migration erneut auszuführen, und importieren Sie die Daten anschließend erneut. Ich würde jedoch vorschlagen, das Commit, bei dem Sie die ursprüngliche Migration durchgeführt haben, erneut auszuführen und die oben beschriebenen Schritte auszuführen. – Anderscc

+1

Ok, nach deinem letzten Satz muss ich die Produktion wieder mit dem lokalen synchronisieren, damit diese Migrationen wieder dieselben sind. Ich mache das und markiere deine Antwort. Vielen Dank! –