Pull to refresh

Comments 35

Пару недель назад внедрял миграции для баз данных. Смотрел на Liquidbase и flywaydb. Выбрали 2й, потому что он понятнее — работает с sql скриптами а не абстракциями. Но даже несмотря на всю простоту, внедрение в команде идёт со скрипом. Пару недель был переходный период когда можно было писать скрипты и для ручного запуска и для автоматического. Команда всё равно выбирала привычный ручной способ. Хотя, вся разница была в том как назвать скрипт и куда положить. Ну и небольшой howto нужно было прочитать.

Я это к тому, что для того чтобы освоиться с liquibase придётся потратить больше времени.

С Liquibase я работал пару лет назад. Liquibase мощнее, но и сложнее в освоении.
Из преимуществ Liquibase (о которых я знаю):


  • независим от базы/диалекта
  • умеет dry-run. Т.е. можно посмотреть какие sql-ы будут сгенерированы
  • умеет rollback (при условии, что описаны сценарии для rollback-а)
    Из минусов:
  • сложнее в освоении, настройке
  • формат описания changeset-ов — xml. У меня был опыт — когда все changeset-ы были описаны в одном большом файле. Разруливать merge конфликты, конфликты версий при работе в большой распределённой команде было сомнительным удовольствием.
Ну то, что ты все changeset-ы в один файл пихал — это ты конечно сам себе злобный Буратино. Ну а уж если, как тут говорят, Liquibase сложнее в освоении, то в сравнении с FlyWay стоит сказать именно так: тяжело в учении, но легко в бою.

Не все так однозначно. Но вводить liquibase в команду даже из 10 человек я не рискнул бы без острой необходимости именно в liquibase-овских фишках.

И какую бы альтернативу автоматическому накату изменений ты бы выбрал?
Что будешь делать, если накат упадет на середине выполнения SQL-файла?

Править скрипт, просить команду быть внимательнее. А если такое будет часто, то писать более гранулярные скрипты. Что тут ещё можно сделать?

Это понятно. После того, как ты устранишь причину падения — ты будешь вынужден либо руками удалить из файла уже выполнившиеся команды/операторы, либо запускать руками оставшуюся часть. В случае с Liquibase ты просто нажал бы повторно кнопочку наката.
UFO landed and left these words here
Не смотрели в сторону dbDeploy? Правда там только порядок выполнения и пропуск выполненных

Последнее обновление от 2009 года. Я смотрел только на более менее живые проекты.

SQL, обвернутый в xml-тег, это уже абстракция?

Абстракция — это описание changeset-a в чистом xml. SQL обёрнутый в тэг — это не абстракция, это извращение. =)

Для тех, кто не знает или боится SQL — возможно. Посмотри диаграмму ораколовой команды create table. При желании сделать что-то не предусмотренное xml-нотацией далеко не уедешь. Да и представь себе, я в changeset-ы не только SQL, но и PL/SQL вставляю. Тебе уже стало страшно?

Я ничего не имею против SQLа. Sql-ы в отдельных файлах — на здоровье. А Sql-ы внутри xml тэгов я считаю извращением. Когда ты один пишешь, пиши как хочешь. Но когда так пишет целая команда, то разобраться в том, к чему этот sql был написан (особенно если это pl/sql) проще когда sql отдельно, а xml отдельно.

Ну это твое субъективное мнение. А вот тебе мое: если мне нужно сделать десяток alter-ов, зачем я буду плодить столько же файлов, мне проще засунуть их в один xml-файл под разными changeset-ами.
Ты хочешь сказать, тебе будет легче разобраться, для чего нужен был конкретный SQL, если он будет в отдельном файле, а не в XML-теге?

Зависит от SQL-a. Если это однострочник типа ALTER TABLE ADD COLUMN — то всё-равно. Если же что-то типа CREATE TABLE, то лучше бы ему быть в отдельном файле.

Как прикажешь делать insert-ы, сложные update/merge?

Преимущества абстракций liquibase это:


  • независимость (теоретически) от базы, liquibase генерит нужный sql код для конкретной базы. "Теоретическая" — потому, что такого требования часто нет, да и периодически все равно требуется что-то делать чистым sql, что уже ломает автоматическую совместимость
  • возможность автоматического rollback, для большинство вещей типа создания таблиц, ключей и т.п. liquibase может автоматически создать "обратную" операцию и откатить изменения. Не то, чтобы их сложно было написать в SQL, но все же
+ Liquibase в отличие от того же Flyway ведет трекинг в бд не по файлам, а отдельным changeset-ам со всеми вытекающими преимуществами.

У flyway даже комментарий в скрипт добавить нельзя после запуска.

Работает ли инструмент с данными или только со схемой? Если работает с данными то каким образом решается такая проблема что данные в различных окружениях (например в продуктовом и тестовом) должны отличатся?
Да, данные на тесте и проде могут отличаться. А в чем проблема? Сформулируйте.

Работает,
просто создаете sql файлы с данными и запускаете их.


Как вы организуете эти файлы под разные энвайронменты — это уже на что фантазии хватит.
Можно просто разные наборы данных иметь, а можно для test подготовить sql который будет править/расширять dev данные.

Простите, что влезаю со своим пэхапе, но
Я считаю очень удобными миграции в yii2. PDO, используемый в фреймворке отлично работает с большинством бд. Поддерживается как чистый sql, так и абстракции. Применяются только новые миграции. В общем, если просто установить php с pdo, можно пользоваться.
Only those users with full accounts are able to leave comments. Log in, please.