Comments 16
Начал изучать Laravel и там тоже есть миграции, на php.
Т.е. sql-файлы в нужном порядке можно выполнить и без всякого GO? Выглядит, как изобретение колеса, простите :)
В теории миграции должны уметь переводить базу из одного состояния в другое самостоятельно. То есть если у вас есть база, структура которой менялась несколько раз по мере развития программы, то если вы запустите последнюю версию, то она должна преобразовать базу к последней версии вне зависимости от того, какая текущая версия. Кроме того структура базы должна была автоматически строится из описания сущностей и взаимосвязей в ORM. Ради того оно всё и изобреталось. Это в теории. На практике оно ни черта так не работает. Точнее работает, но только для самых простых баз, а как только начинаем использовать что-то сложное и зависящее от конкретной реализации SQL, то сразу "Ой". А ещё оказалось, что часто при изменении структуры базы нужно ещё и данные в базе изменять нетривиальным образом, и тогда к красивой миграции приписывается куча кода, который очень все мечты об автогенерации. Ну, и в какой-то момент программисты, как обычно, стали миграциями заменять чуть ли не рукописное описание структуры базы, создав совершенно лишнюю сущность поверх SQL. На хрена это делается, и что именно экономится, никто зачастую толком объяснить не может, рассказывая абстрактные умные слова про миграции и автогенерацию, несмотря на то, что в реальности там внутри всё уже на костылях и подпорках и прибито к конкретной версии конкретной базы с кучей кастомного кода для преобразования базы от одной версии структуры к другой. Короче, всё как всегда.
Угу, нет никаких возможностей одну структуру БД перевести в другую корректно и без явно указанных миграций. ORM тоже никак не избавляет от миграций (да и создавался для других вещей).
Впрочем, в статье практически ничего полезного не сказано о миграциях.
Так-то и команды добавления колонки могут подвесить базу (если одновременно идет длинный отчет). А команда создания индекса опасна почти всегда. А кроме изменений структуры данных нужно еще обновить и сами данные и для этого нужно писать специальный движок (так как просто сделать update на большой базе не получится).
И миграции надо тестировать (чтобы они боевую базу не убили), иногда откатывать (что почти всегда нетривиально), в процессе миграций поддерживать совместимость - и так далее и так далее.
Только SQL для этого, увы мало, все равно нужна внешняя обвязка, как минимум для идемпотентности миграций.
Есть https://github.com/c9s/goose , который является форком https://github.com/pressly/goose , который является форком https://bitbucket.org/liamstask/goose/src/master/
Угу, нет никаких возможностей одну структуру БД перевести в другую корректно и без явно указанных миграций.
Иногда и с ними - невозможно. И требуется чистый SQL-код. Пример - перемещение поля из одной таблицы в другую, которое в принципе не выполняется в рамках миграции, так как требует удаления триггеров перед перемещением данных и их восстановления после. То есть процесс перехода от старой версии к новой требует модификации объектов БД, которые не изменяются при переходе от начального состояния к конечному без учёта промежуточных.
Хотя... я вообще как-то не понимаю разницу между чистым SQL-кодом и тем, что называется "миграция". По-моему, вся разница - исключительно в том, что именно запустит набор DDL-запросов на исполнение.
А как это связано? ORM это слой над sql, позволяющий более легко и универсально формировать запросы к бд, миграции - это накатывание изменений в бд, они могут например добавить колонку, изменить тип текущий, исправить данные в бд и т. д. Использовать или нет ORM в миграциях зависит только от его наличия уже в проекте.
И самое важное в миграциях должен быть откат их, если что-то пошло не так чтобы можно было очень быстро вернуть бд в прошлое состояние и разбираться с проблемой
Ps мигратор пишется с 0 за пол часа со всем базовым функционалом включая контроль прошедших миграций и прочего
И самое важное в миграциях должен быть откат их, если что-то пошло не так чтобы можно было очень быстро вернуть бд в прошлое состояние и разбираться с проблемой
А вот тут - проблемка. Формально изменение структуры и данных может быть необратимым. Например, переход от BIGINT AUTOINCREMENT к UUID, который сопровождается удалением старых синтетических ключей. Или изменение модели, когда штамп времени признан избыточным, а хранение только даты (или иное понижение точности поля таблицы) - целесообразным.
Мне нравится подход в django - миграции строятся автоматически при изменении модели данных. руками это всё писать - такое себе развлечение.
Я пришел в го из джанги, по этому когда пришлось прописывать таблицу вручную впал в небольшой ступор) Иногда слышу что ОРМ не всегда оптимально создает эти миграции и хочется иметь возможность подкрутить узкие места. Не сталкивался в своей практике с таким. Если применял джангу то для создания MVP, а там ОРМ за глаза)
На node-проектах используем Prisma, генерит из схемы весьма приличные миграции (ну и в использовании удобна)
Не очень понятно из статьи, чем де-факто полустандартный gorm не угодил?
Большое количество библиотек подключено - но они как-то все не очень распространены.
Использование миграций баз данных в Go