Symfony 4: как безопасно «соединять» миграции вместе? / удалить миграции между первой и последней?

В целом да, вы можете. Но вы должны знать о том, что Doctrine/Migration сохраняет выполненные миграции в БД. Поэтому вам следует удалить ненужные файлы миграции (возможно объединить все запросы в один), после этого обновить базу данных.

Имя таблицы по умолчанию "доктрина_миграция_версия", просто удалите ненужные строки версии

Нет, в общем, вы не должны делать ни того, ни другого. Позвольте мне начать с прояснения того, что кажется неправильным: миграция не содержит полной схемы базы данных, только запросы, необходимые для переноса базы данных из одной версии в другую. Эта система позволяет управлять изменениями базы данных и контролировать их версии. Таким образом, вы должны начать видеть некоторые проблемы с этим:

• Миграция может зависеть от предыдущей. Например. v1 добавляет сущность, а v2 добавляет новое поле. Если вы удалите v1, v2 будет сломан, и его также необходимо удалить.
• Поскольку миграция базы данных как правило идет рука об руку с изменением объектной модели, вам также придется отменить модель, иначе вы обнаружите проблемы с сопоставлением с несуществующими полями.

Это может быть приемлемо на этапе проектирования, когда у вас еще нет никаких функций. Вы можете отменить отдельную миграцию, используя bin/console doctrine:migrations:execute --down <version>. Обычно это делается во время тестирования изменений, если необходимо внести коррективы. Но обычно, когда это изменение еще не зафиксировано.

Doctrine отслеживает миграции с помощью таблицы базы данных под названием migration_versions. Называя их датой, он может упорядочивать их и применять последовательно. Всякий раз, когда миграция выполняется, она добавляет имя миграции в эту таблицу. При откате удаляет из таблицы вместе с полями в самой миграции. Имейте в виду, что даже если вы можете откатить миграцию, это не значит, что все будет так, как было. Если при миграции удаляется столбец, он будет воссоздан при откате, но данные будут потеряны.

Насчет "можно ли это сделать"? да. Если вы действительно очень хотите, внимательно прочитайте документация и осознайте все это.

Итак, поскольку ваш вопрос касается слияния миграций, давайте рассмотрим ваши фактические варианты:

• Могу ли я удалить их вручную (щелкните правой кнопкой мыши в PHPStorm, затем «Удалить»), а затем перейдите в командную строку и выполните php bin/console doctrine:migrations:migrate?

Нет, это не сработает. migrate будут миграции применить доступный. Их не будет, и, как объяснено, ревизии все еще будут в таблице, и ее изменения будут применены.

• Или мне нужно сделать php bin/console doctrine:schema:update?

Это тоже ничего не даст, так как сравнит модель с базой данных и обнаружит, что они совпадают.

В любом случае вам нужно будет сначала восстановить их, а затем создать эквивалентный. Команда для этого doctrine:migrations:diff. Это сравнит модель со схемой и сгенерирует миграцию для синхронизации базы данных. И чтобы это работало, вам нужно сначала execute --down выполнить миграции, иначе они не будут иметь никаких изменений, но могут привести к потере некоторых данных в процессе.

Если вы работаете в команде, миграция исчезнет. Некоторые могут даже отставать в истории и не применять все миграции. Вскоре это станет проблемой управления. Есть команда rollup, которая (насколько я понимаю и никогда ее не использовала) очищает устаревшие миграции из таблицы, выгружает полную схему и применяет ее. Это будет ваш лучший выбор, но имейте в виду, что это, скорее всего, удалит ваши данные.

Вы также можете комбинировать миграции вручную. Это просто классы с методами up и down. Объедините все тела функций, примените процесс очистки и закройте его.

Теперь, если вы хотите сделать это, это не должно быть большой проблемой. Просто замените свои устаревшие версии на новые и предупредите об этом всех. Но если вы хотите сделать так, как будто их никогда не существовало, и вести аккуратную историю коммитов, тогда ваши товарищи по команде потенциально захотят вас убить, поскольку это будет связано с переписывая историю. Когда вы это сделаете, им придется перебазировать всю свою работу.

Если вы хотите сделать это:

• Делайте резервные копии
• Внесите свои изменения как можно раньше, чтобы избежать перерывов. Это нормально, если в базе данных какое-то время есть неиспользуемые поля, пока модель не наверстает упущенное. Если вы сделаете это поздно и это понадобится какому-то объекту, кто-то может быть вынужден создать миграцию и сломать вашу миграцию в процессе.
• Сделать это правильно (желательно с первой попытки). Не настаивайте, пока не протестируете всесторонне.
• Делайте резервные копии

Ссылка на консольные команды

Не существует «безопасного» способа сделать это, но если вы не развернули миграции, вы можете безопасно выбросить серию автоматически сгенерированных миграций и создать их заново. Просто будьте осторожны, чтобы не выбросить SQL ручной миграции одновременно.

Обычно на этапе проектирования мы:

1. Используйте doctrine:schema:update --force, пока все не станет достаточно стабильным
2. После того, как они станут стабильными, мы сбрасываем базу данных разработки из снапшота.
3. Запустите doctrine:migrations:diff, а затем добавьте вручную запросы на миграцию, где это необходимо.

Возможно, вам нужно игнорировать все ваши миграции и сосредоточиться на последнем состоянии схемы базы данных. Если это то, что вы хотите получить в финале, вы можете просто нажать: php bin/console doctrine:schema:update --dump-sql, чтобы получить соответствующий оператор SQL, или нажмите php bin/console doctrine:schema:update --force, чтобы применить его к базе данных.