Можно ли написать изменение Sqitch, которое удаляет столбец, без обреченной проверки sqitch на вечный сбой? - PullRequest
0 голосов
/ 14 апреля 2020

Этот вопрос задается c для Sqitch, но может иметь отношение к другим инструментам управления миграцией базы данных.

Первое изменение Sqitch в моем приложении определяет его общую схему: он создает все таблицы таблиц и определяет их столбцы.

Допустим, первое изменение называется appschema, а одна из создаваемых таблиц - lessons со столбцами chapter, section и title.

.

Теперь, через пару уже развернутых изменений, я хочу удалить столбец title из таблицы lessons.

Я запускаю sqitch add move_lesson_titles_out_of_db и пишу сценарий deploy этого изменения как

ALTER TABLE lessons DROP COLUMN title;

Я sqitch deploy, что для моей локальной цели разработки, и она работает, как ожидалось.

Но теперь sqitch verify dev терпит неудачу, потому что изменение appschema сценарий проверки подтверждает, что столбец title существует. До сих пор я мог запускать sqitch verify dev, и все предыдущие изменения проходили. Возможно, это мое недоразумение, но у меня сложилось впечатление, что все изменения должны продолжать проверяться при запуске по порядку на правильно развернутой и обновленной цели Sqitch.

I может sqitch rework appschema вместо , добавляя изменение, но документация Sqitch очень ясна , что как исходное, так и переработанное изменение должно быть идемпотентным, и, поскольку appschema содержит группу CREATE TABLE с, она уже не идемпотентна . Кроме того, если я правильно понимаю sqitch, развертывание этой переработанной appschema вернет всех моих изменений (поскольку это первое изменение в моем плане) обратно в пустую базу данных, а затем воспроизведет все обратно.

Я бы получил правильную схему, но за счет стирания всех данных. Очевидно, что я не планирую что-либо делать с производственной целью.

Есть ли лучший способ добавить изменение, которое отбрасывает столбец, не обрекая sqitch verify на более раннее изменение, создавшее этот столбец? Или это ошибка проверки по замыслу?

Если по замыслу, есть ли еще какой-то способ извлечь выгоду из проверки многих других вещей, которые изменение appschema делает убежищем? t впоследствии изменилось (а именно, определение всей остальной части схемы моего приложения)?

...