2016-03-20 9 views
7

Powiedzmy, mam wiele plików migracyjnych aktualizujących jedną tabelę.Laravel migrować - wiele migracji (plików) za jednym razem

np.

 
2016_03_20_072730_create_tasks_table.php 
2016_03_20_075467_create_tasks_table.php 

... która pochodzi z repo przez różnych członków zespołu. Każdy dostosowuje coś w tabeli, np. dodanie kolumny.

Kiedy próbuję:

php artisan migrate

otrzymuję błąd:

 
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 

Jak należy radzić sobie z sytuacji jak opisana powyżej?

EDIT

Oto kod:

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

Odpowiedz

7

Każda migracja musi mieć unikalną nazwę klasy. Zmień nazwę na coś bardziej sensownego, na przykład 2016_03_20_075467_add_task2_to_tasks_table i AddTask2ToTasksTable, a następnie uruchom composer dump-autoload, aby Laravel znalazł zmiany. Teraz możesz migrować.

Edycja: Teraz, gdy do tego edytowano kod obu migracji, widzę, że pierwsza migracja ma ten sam problem i powinna zostać zmieniona w ten sam sposób. Najprawdopodobniej początkowa migracja do tworzenia jest nieco późniejsza. Powinieneś przestać nazywać migracje edycyjne czymkolwiek z create, ponieważ tak naprawdę nie tworzysz tabeli.

+0

Tak, doszedłem do tego samego wniosku z błędem, ale migracja miała być o wiele większa niż wykonanie DB ręcznie. Podobno powinieneś po prostu uzyskać najnowsze repozytorium, uruchomić migrację i wypić piwo. Wygląda jednak na to, że aktualizacje ręczne nie są zbyt daleko w tyle za tą "super najlepszą rzeczą od krojonego chleba";) Teraz musisz albo zmodyfikować plik migracyjny, połączyć pliki migracyjne, albo przenieść każdy do temp i użyć - -path, itp. Tak, myślę, że to jest cytryna. Dużo gadaj, mała rączka. Chyba że jest łatwy sposób - stąd moje pytanie. – Jeffz

+0

To jest łatwe - musisz tylko nazwać swoje migracje logicznie. Nie musisz nic robić w bazie danych. Ujmijmy to w ten sposób: praca z modelami jest naprawdę łatwa. Ale jeśli spróbujesz nazwać dwa modele tą samą rzeczą, to nie zadziała. Czy uważasz, że sprawia to, że modele również są trudne do pracy? :) Po prostu ucz swoich członków zespołu, aby nadali różne nazwy różnym imigracjom i dosłownie wszystko, czego potrzebujesz. –

+1

Pliki migracji są automatycznie tworzone przez Laravel. Skoro istnieje skrót do tworzenia, czy Laravel będzie tak trudno dodawać losowy ciąg/hasz do nazwy klasy? Chyba że jest coś, co krzyczy przeciwko tej procedurze. Dziękuję Joel za poświęcony czas. – Jeffz

Powiązane problemy