Ржачне ящитаю
…Поэтому у меня нет необратимых миграций. Если я удаляю таблицу или столбец, в ролбеке я ее создаю. В данном случае удаленные данные уже не важны, главное — не нарушать цепочку миграций, так чтобы всегда можно было отойти к самому началу и вернуться в исходную точку.
Поэтому я всегда пишу и тестирую откаты (–up; –down; –up). И бывает, что падают.
интересно, какое обратное действие для drop table?
зачем вообще делать ролбэки я не понимаю
если они еще не обкатаны или вы накатываете на PROD, тогда их надо запускать по одной:
./symfony doctrine:migrate –up
А все потому, что когда вы обновляетесь одним махом, например со 2 по 10 версию, и у вас падает какая-то миграция (причем неизвестно какая), то номер версии не обновится и останется 2, хотя реальный номер может быть 5. И тогда приходится находить упавшую миграцию, править номер версии в БД, чтобы откатиться и чинить миграцию.
а что, доктрина не хранит выполненные миграции в самой базе? точнее, не записывает что миграция выполнена сразу после её выполнения? и ей что-то мешает выводить рантайм-лог - "миграция такая-то начата…закончена"?
ну и т.д.:
Обнуление миграций
Меня заинтересовала эта идея — время от времени удалять все миграции, большая часть которых уже стала избыточной и требует много времени для создания тестового окружения. Можно снова написать первую миграцию для начального импорта и изменить номер миграции в БД.
человеку делать нехуй
Не знаю как в Symfony, но в Rails миграции делаются в транзакциях.
особенно учитывая что транзакции при альтерах бесполезны чуть более чем полностью. по крайней мере в мускуле