php - llaves - Las migraciones de Laravel son una buena forma de deshabilitar las comprobaciones de claves externas.

rename column laravel

Question

Al ejecutar migraciones de laravel, me enfrento a un pequeño inconveniente. Yo uso Laravel 5.1.

Dado que hay muchas tablas con muchas relaciones, es probablemente imposible que cambie el nombre de los archivos de migración para que se ejecuten en el orden correcto, por lo que no se infringe ninguna restricción de clave externa. Esto fue lo que hice una vez en el pasado, y fue muy poco práctico.

Lo que estoy haciendo ahora es definir cada migración de esta manera:

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

El problema con esto es que es tedioso escribir y desordena el código.

También he pensado en crear dos archivos de migración ficticios, cuyo único propósito sería habilitar y deshabilitar las comprobaciones de claves externas, y los nombraría de tal forma que se ejecuten al principio y al final de cada migración.

Si existe una solución elegante, también sería posible aplicarla al proceso de siembra, ya que esto también suele ser un problema.

Obviamente, esta es una solución muy improvisada, y estoy preguntando si hay una mejor manera de hacerlo. ¿Hay algunos métodos afterMigrate beforeMigrate y después de afterMigrate que puedo anular o algo así?

Y si no, ¿cómo lo haces?

Cualquier apreciación sería apreciada, no me gustan todas las opciones que he indicado.

Answer 1

A veces, la mejor manera de hacer esto es eliminar siempre las claves externas creadas en su código de migración de retroceso.

Digamos que tiene una clave foránea en su esquema de up la siguiente manera:

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

En su migración down , debería tener

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

Answer 2

Logré esto extrayendo la lógica de la clave externa en un archivo de migración separado. Esto me ayudó a:

• Deshabilitar las restricciones de clave externa.
• Suelte la base de datos de forma segura, si existe.

En codigo:

//file: 2017_06_19_230601_fk_postuser_table.php
public function down()
{
Schema::disableForeignKeyConstraints();
Schema::dropIfExists(''post_user'');
}

Answer 3

Otro aspecto importante que se debe recordar es colocar el foreignKey PRIMERO, luego la columna. Bajando la columna primero arroja el error:

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

El orden apropiado importa:

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

Answer 4

Tenía una tarea similar a mano cuando Lumen / Laravel comenzó a usar Passport y tuve que deshacerme de la implementación previa del servidor lucadegasperi/oauth2-server-laravel de lucadegasperi/oauth2-server-laravel .

Finalmente logré poner las cosas en marcha creando 2 migraciones, donde la primera borra las claves externas y la segunda elimina las tablas.

Tuve que usar fechas antes de las migraciones del Pasaporte de Laravel (2016-06-01) para que se ejecuten antes de esas.

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

Y en el segundo archivo 2016_05_31_000001_clear_old_oauth.php

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