поломать внешние ключи? (и не наспамить новых под шумок)
Эээ.. а Вам зачем? С конкретной таблицей это сложно сделать, и готового решения для автоматического пересоздания я не видел, кажется... а Вы искать в интернете пробовали?
Спасибо В интернете искал где-то полдня, ничего не нашел толком и потому пришел сюда Вообще меня беспокоят миграции. Миграций в команде очень много. Со временем хочется их схлопнуть и очистить папку. При этом иметь возможность выгрузить таблицы, проверить их вручную и залить обратно, не пересоздавая всю базу с нуля
1. Забекапить ДАННЫЕ из всех связанных таблиц. 2. Дропнуть ДАННЫЕ из всех связанных таблиц, в порядке, обеспечивающим работоспособность ссылочной целостности. 3. Пересоздать нужную таблицу. 4. Накатить данные из бекапов, в обратном удалению порядке. Это абсолютно безопасный способ. Но я присоединяюсь к вопросу: зачем? Чтобы новый столбец был не в конце а в начале? Не стоит оно того.
Понял, значит буду генерить yaml конфиг по энтитям, и уже из yaml-ов генерировать миграцию Когда нужно будет схлопнуть буду перегенерировать yaml из существующей базы, двигать поля, затем создавать миграцию включающую все остальные В конфиге смогу поменять порядок полей Схлопывание - задача регулярная Порядок полей - задача едва ли не разовая. Перед выкаткой проекта, и раз в год потом
Чёт как-то сложно. Напиши SQL скрипт, который будешь выполнять по крону.
Я про это и спрашивал... как сделать такой sql скрипт чтобы можно было переделывать бд и контроллить её потаблично. Но как вы и сказали (и как я предполагал) не снеся всю цепочку так не получится
Я просто не понял вопроса. Руками, конечно. Пишем, что дропаем, порядок важен, потом криейтим и льём данные из бекапа.
В мускле можно было на порядок положить ))) не работал только транкейт, остальное FK_DISABLE решал, здесь replication_role replica и DISABLE TRIGGER ALL не спасает)) Спасибо
Обсуждают сегодня