Как именовать миграции, что бы избежать конфликта имен классов?
Здравствуйте! Как правильно именовать миграции, что бы избежать конфликта имен классов миграций?
Приведу пример, правда вымышленный, но суть отражает полностью. Допустим, создали миграцию с именем create_examples_table (имя класса CreateExamplesTable), которая в свою очередь создаст таблицу в базе данных. Через какое-то время мы эту таблицу решили удалить и создали соответствующую для этого миграцию. А спустя еще время решили, что эта таблица все же нужна и опять создали миграцию под именем create_examples_table (имя класса CreateExamplesTable). В итоге у нас получился конфликт в именовании классов, и при выполнении, например, команды php artisan migrate:reset мы получим ошибку.
Можно конечно добавлять к имени миграции дату, но это на мой взгляд так себе решение. UPD: под добавлять к имени миграции дату имелось ввиду добавлять дату не вручную, а сделать обертку над стандартной командой make:migration.
Проблема высосана из пальца.
Ну случился у вас конфликт - добавили "2" к классу, выполнили dump-autoload и все! Такое впечатление, что вы через день удаляете и восстанавливаете таблицы.
первая миграция создает таблицу
потом вам через месяц преспичело удалить таблицу - делаете миграцию где на UP у вас sql запрос в стиле DROP TABLE, но на методе down() вы должны СОЗДАТЬ ЭТУ ТАБЛИЦУ как и было раньше
все миграции должны до начала откатываться и подниматься
как файл миграции с таким же названием может существовать? вы их вручную клепаете?
там же почти рандомный префикс в названиях классов, если через генератор
дропните бд полностью
исправьте код миграций и накатите заного
как файл миграции с таким же названием может существовать? вы их вручную клепаете?
там же почти рандомный префикс в названиях классов, если через генератор
Читайте внимательно. Файлы называются по разному. Но классы внутри них - одинаково. Различие только в префиксе в названии файлв.
все миграции должны до начала откатываться и подниматься
До начала чего? Продукт в лайве. Вы предлагаете почистать базу?
php artisan make:migration CreateCommentsTable
Created Migration: 2017_11_09_122738_CreateCommentsTable
Вот что внутри
<?php
use Illuminate\Support\Facades\Schema;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Database\Migrations\Migration;
class CreateCommentsTable extends Migration
{
/**
* Run the migrations.
*
* @return void
*/
public function up()
{
Schema::create('comments', function (Blueprint $t) {
$t->increments('id');
$t->timestamps();
});
}
/**
* Reverse the migrations.
*
* @return void
*/
public function down()
{
Schema::drop('comments');
}
}
Далее ситуация такая. Клиент отказывается от функционала комментариев. Говорит, что бизнесу это вредит. Всё с вязанное с этим выпиливается. Код чистится.
php artisan make:migration RemoveCommentsTable
Created Migration: 2017_11_09_123257_RemoveCommentsTable
<?php
use Illuminate\Support\Facades\Schema;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Database\Migrations\Migration;
class RemoveCommentsTable extends Migration
{
/**
* Run the migrations.
*
* @return void
*/
public function up()
{
Schema::drop('comments');
}
/**
* Reverse the migrations.
*
* @return void
*/
public function down()
{
Schema::create('comments', function (Blueprint $t) {
$t->increments('id');
$t->timestamps();
});
}
}
Через год, клиент увидел, что у его конкурента комментарии оченьдаже не плохо взлетели. И он решает добавить их обратно.
По идеологии названий, мы создаём новую миграцию с таким же названием.
php artisan make:migration CreateCommentsTable
Но получаем ошибку.
[InvalidArgumentException]
A CreateCommentsTable migration already exists.
. А теперь суть вопроса автора. Как правильно давать названия миграциям, что бы не возникало таких коллизий? То есть как правильно их обозвать именно здесь?
Ну есть старое правило - называть миграции максимально многословно, чтобы такого не случалось. create_table_for_examples_again например. Ты же в названиях миграций не ограничен ничем, никакими правилами совместимости или соглашениями по стилю кода.
