2016-03-20 13 views
7

Supponiamo, ho più file di migrazione che aggiornano una singola tabella.Laravel migrate - più migrazioni (file) in una volta

ad es.

 
2016_03_20_072730_create_tasks_table.php 
2016_03_20_075467_create_tasks_table.php 

... che proviene da un repo di membri di diversi team. Ciascuno sta modificando qualcosa nella tabella, ad es. aggiungendo una colonna.

Quando provo a:

php artisan migrate

ottengo l'errore:

 
PHP Fatal error: Cannot declare class CreateTasksTable, because the name is 
eady in use in U:\www\b10\database\migrations\2016_03_20_072737_create_tasks_ 
le.php on line 30 


    [Symfony\Component\Debug\Exception\FatalErrorException] 
    Cannot declare class CreateTasksTable, because the name is already in use 

come si dovrebbe affrontare la situazione come sopra descritto?

EDIT

Ecco il codice:

2016_03_20_072730_create_tasks_table.php:

 
class CreateTasksTable extends Migration 
{ 
    /** 
    * Run the migrations. 
    * 
    * @return void 
    */ 
    public function up() 
    { 
     Schema::table('tasks', function ($table) 
     { 
      $table->string('task1'); 
     }); 
    } 

    /** 
    * Reverse the migrations. 
    * 
    * @return void 
    */ 
    public function down() 
    { 
     Schema::drop('tasks'); 
    } 
} 

2016_03_20_075467_create_tasks_table.php:

 
class CreateTasksTable extends Migration 
{ 
    /** 
    * Run the migrations. 
    * 
    * @return void 
    */ 
    public function up() 
    { 
    Schema::table('tasks', function ($table) 
     { 
      $table->string('task2'); 
     }); 
    } 

    /** 
    * Reverse the migrations. 
    * 
    * @return void 
    */ 
    public function down() 
    { 
     Schema::drop('tasks'); 
    } 
} 

risposta

7

Ogni migrazione deve avere un nome classe unica. Rinominare il secondo a qualcosa di più sensato, come ad esempio 2016_03_20_075467_add_task2_to_tasks_table e AddTask2ToTasksTable, quindi eseguire composer dump-autoload per fare in modo che Laravel trovi le modifiche. Ora puoi migrare.

Modifica: ora che il codice di entrambe le migrazioni è stato modificato nella domanda, posso vedere che la prima migrazione ha lo stesso problema e deve essere rinominata nello stesso modo. Probabilmente c'è una migrazione iniziale di creazione a un certo punto più indietro. È necessario interrompere la denominazione delle migrazioni di editazione con qualsiasi cosa con create, poiché in realtà non si sta creando la tabella.

+0

Sì, sono giunto alla stessa conclusione per errore, ma la migrazione doveva essere molto più grande di fare DB a mano. Si suppone che si dovrebbe ottenere l'ultimo repo, eseguire migrare e bere una birra. Ma con questo, sembra che gli aggiornamenti manuali non siano così lontani da questa "cosa superlativa dopo il pane affettato";) Ora, devi aggiustare il file di migrazione, combinare i file di migrazione o spostarli ciascuno in temp e usare - -percorso, ecc. Quindi, immagino che sia un limone. Un sacco di chiacchiere, piccola maniglia. A meno che non ci sia un modo semplice - da qui la mia domanda. – Jeffz

+0

È semplice: devi solo nominare le tue migrazioni logicamente. Non devi fare nulla nel database. Mettiamola così: è davvero facile lavorare anche con i modelli. Ma se provi a nominare due modelli la stessa cosa, non funzionerà. Vorresti sostenere che anche i modelli siano difficili da lavorare? :) Insegna ai membri del tuo team di dare nomi diversi a migrazioni diverse e questo è letteralmente tutto ciò di cui hai bisogno. –

+1

I file di migrazione sono creati automaticamente da Laravel. Dato che esiste una scorciatoia per la creazione, sarebbe molto difficile per Laravel aggiungere qualche stringa casuale/hash al nome della classe? A meno che non ci sia qualcosa che urla contro questa procedura. Grazie Joel per il tuo tempo. – Jeffz