В этой статье мы поговорим о Flyway и Liquibase — двух наиболее популярных инструментах на основе Java для рефакторинга баз данных. Цель статьи — сравнить эти инструменты и выяснить, какой из них в каких случаях лучше применять.


DB omnibus


Flyway


Концепция Flyway сосредоточена вокруг шести различных команд для поддержки автоматизированного рефакторинга и версионирования БД. Эти команды могут исполняться из командной строки, в процессе сборки (производимого с помощью Maven или Gradle) или непосредственно из Java-кода с помощью вызовов API. При исполнении этих команд вам необходимо предоставить параметры подключения к той БД (url, имя пользователя, пароль), которую вы хотите рефакторить.


Основная команда называется migrate и выполняет функцию, в которой заключается вся суть рефакторинга БД: она сканирует специальную папку с sql-скриптами (у каждого из которых в имени файла указан номер версии) и проверяет, какие из них уже применялись к целевой базе данных. Затем она исполняет те из них, которые еще не применялись к этой БД. В случае возникновения противоречий, например, если уже примененный скрипт изменился со времени его применения, Flyway прерывает процесс своей работы сообщением об ошибке.


Уникальной чертой Flyway является то, что скрипты миграции могут быть не только в формате SQL, но и в виде Java-кода. Второй вариант позволяет реализовывать динамические миграции со сложной логикой. Однако использовать Java-подход следует с осторожностью, так как подобные скрипты миграции обычно тяжело дебажить, если в них что-то пошло не так.


Помимо основной команды migrate у Flyway есть дополнительные команды, облегчающие процесс рефакторинга БД.


Команда info показывает все доступные скрипты миграции из заданной папки и отмечает, какие из них уже были использованы, а какие только будут применены к целевой БД.


Чтобы проверить, изменялись ли скрипты, примененные к БД, используется команда validate. Нам полезно знать, был ли уже примененный скрипт из папки изменен с момента его применения к БД, потому что это может означать, что скрипт применялся к разным БД в разных версиях, а это может вызывать проблемы.


Если вы считаете, что скрипты нужно применять несмотря на сбой, показанный командой validate, то можно запустить команду repair. Она сбросит таблицу БД, используемую Flyway для фиксации того, какие скрипты были уже применены (по умолчанию эта таблица называется SCHEMA_VERSION).


И последняя, но не менее важная, команда clean полностью очищает выбранную схему (как вы понимаете, эта команда должна использоваться только для тестовых БД).


Liquibase


Liquibase использует другой подход к реализации рефакторинга БД. В отличие от Flyway, которая поддерживает скрипты миграции только в форматах SQL и Java, Liquibase позволяет абстрагироваться от SQL и таким образом устранить привязку рефакторинга базы данных к ее конкретной реализации.


Вместо SQL-скриптов, Liquibase поддерживает скрипты миграции в форматах XML, YAML и JSON. В этих скриптах вы определяете изменения в БД на уровне абстракций. Для каждого изменения Liquibase имеет соответствующий элемент в XML, YAML и JSON. Например, изменение, создающее новую таблицу БД в формате YAML выглядит так:


createTable:
  tableName: Customer
  columns:
  - column:
      name: name
      type: varchar(255)
  - column:
      name: address
      type: varchar(255)

Изменения типа add column, create index или alter table и другие выглядят схожим образом.
Во время работы Liquibase автоматически применяет все скрипты, которые еще не применялись, и, как и Flyway, сохраняет их метаданные в специальную таблицу БД. Аналогично Flyway, Liquibase можно вызвать из командной строки инструментов сборки или непосредственно через его Java API.


В каких случаях их использовать?


И Flyway, и Liquibase поддерживают все функции, необходимые для профессионального рефакторинга и версионирования БД, так что вы всегда будете знать, с какой версией схемы БД вы имеете дело и соответствует ли она версии вашего ПО. Оба тула интегрированы с Maven и Gradle и в экосистему Spring Boot, так что рефакторинг БД можно полностью автоматизировать.


Flyway использует SQL для определения изменений БД, так что можно настроить SQL-скрипты так, чтобы они эффективно работали с конкретными типом базы данных на вашем проекте, например с Oracle или с PostgreSQL. С другой стороны, Liquibase вводит дополнительный уровень абстракции с помощью XML, YAML или JSON для определения изменений БД. Таким образом, Liquibase лучше подходит для ПО, которое нужно устанавливать в разных окружениях с разными типами серверов БД. Однако если вам нужен полный контроль над вашим SQL, ваш выбор — Flyway, так как он позволяет изменять БД с помощью полностью кастомного SQL или даже с использованием Java-кода.


Подвох с обоими инструментами в том, что они поддерживаются одним человеком (от переводчика: по информации автора), а не большой командой. Это может оказать негативное влияние на будущее развитие обоих тулов, однако это не обязательно. На момент написания этой статьи активность в GitHub-репозитории Flyway выше, чем в репозитории Liquibase.

Комментарии (9)


  1. aol-nnov
    18.02.2019 12:33
    +1

    только я со взглядом горячим, потирая потные ручонки в предвкушении, клацнул по ссылке с таким вкусным заголовком, как статья раз, и закончилась… печаль…


    1. Dyakonoff Автор
      18.02.2019 12:38

      Ну тут я ничего не могу поделать, оригинальная статья тоже небольшая. Главная идя тут все же дать людям, не знакомым с этими решениями направление куда дальше копать ))


    1. eugenius_nsk
      18.02.2019 13:04
      +1

      Мало того, что статья крайне маленькая, так она ещё и неверная. В Liquibase совершенно спокойно можно писать changeset-ы как на чистом SQL, так и на Java. Откуда взялась информация про «поддерживаются одним человеком» — вообще не понятно. Оба продукта очень зрелые и каждый поддерживается и развивается коммерческими компаниями (в случае Liquibase это Datical, в случае Flyway — Boxfuse). Ну и т.д.


  1. tavi
    18.02.2019 12:55

    Нужно заметить, что Liquibase вполне себе поддерживает использование произвольного SQL-кода, для этого есть тег

    <sql>


    1. Dyakonoff Автор
      18.02.2019 14:21

      Есть, не спорю. Однако, это скорее вспомогательный подход для Liquibase.
      При переводе оригинала, я несколько неудачно сформулировал фразу на русском, так сто она понималась как то, что Liquibase не позволяет использовать SQL вообще. ((


      Текст перевода поправил.
      Еще раз спасибо за замечания.


  1. SnowBearRu
    18.02.2019 13:55

    И даже больше, в Liquibase можно чанжсеты в sql файлах писать, управляя миграциями с помощью комментариев https://www.liquibase.org/documentation/sql_format.html, хотя такой подход все равно ограничен по сравнению со стандартными.


  1. Vicking
    18.02.2019 23:10

    В пользу liquibase еще хочу заметить наличие ролбеков из коробки (правда не для всех операций, но для большинства).
    Очень удобно: обновил БД, не работает ПО, вернул обратно.


  1. toklian
    18.02.2019 23:59

    Автор статьи, по какой-то причине, забыл упомянуть, что миграции liquibase могут включать роллбек шаги. Таким образом, там где Flyway просто упадет, liquibase может остановиться на проблемном месте и откатить операцию с ошибкой.


  1. foal
    20.02.2019 09:20

    Если нужен только SQL + Java, то я за Flyway. Он легче, заточен на это. Легко позволяет иметь в одной базе несколько независимых модулей.