Flyway: управление миграциями баз данных

[krestjaninoff]

В ряде случаев (да, далеко не во всех) откат изменений вполне возможен. Поэтому, на мой взгляд, разработчики зря отказались от этой фичи, которая лично меня в dbdeploy время от времени выручает. Откаты БД, конечно же, автоматом никто не делает, но порой иметь на руках готовый для этого скрипт — архиполезно!

[MzMz]

Статья будет неполной без упоминания ближайшего аналога — пакета liquibase, который позволяет описывать структуру объектов БД в виде XML-описания и, как следствие, позволяет делать откаты и многое другое.

www.liquibase.org/

[forketyfork]

Я решил ограничиться упоминанием сравнительной таблички различных решений (в том числе LiquiBase) на странице Flyway. От LiquiBase меня отпугнуло именно XML-описание изменений. Когда идёт речь о миграциях, то хочется быть «ближе к телу», т.е. к SQL. Меньше будет turnaround при написании и отладке скрипта, да и опыт показывает, что случается необходимость быстро накатить изменения скриптом, минуя систему миграции.
Кроме того, не вполне понимаю, как XML-формат связан с возможностью отката миграций. В случае Flyway это вполне обоснованное техническое решение by design, т.к. ничего не стоило бы включать в пакет изменений SQL-скрипт, восстанавливающий базу.

[MzMz]

Тем, что в XML описывается суть изменений в виде мета-описания, а не сам SQL-скрипт, отягощенный подробностями реализации конкретной СУБД. Это позволяет описать изменение один раз — вместо двух SQL-скриптов: на создание изменений и на их откат (что увеличивает риск ошибки вдвое).

Но, если это необходимо Liquibase позволяет внедрить в описание и обычный SQL-скрипт.

И в XML нет ничего страшного.

[forketyfork]

Я не имею ничего принципиального против XML. Но в том-то и дело, что при достаточно сложных изменениях (а они никогда не бывают простыми, особенно на непустой базе, когда требуется определить логику реструктуризации данных) без SQL-скрипта не обойтись. Стоит ли городить ради этого XML, если всё равно придётся предусматривать SQL-вкрапления.

[maxidler]

Странно, но практически ни один инструмент миграции не позволяет делать следующее: Залезть ручками в БД, поменять все так, как нужно, а затем, перед коммитом, сгенерить скрипт различий со старой структурой. ПОЧЕМУ??? Я знаю только пару инструментов, позволяющих такое безобразие…

[forketyfork]

Думаю, это связано с тем, что эта задача достаточно сложная, и в общем виде нерешаемая, особенно когда речь заходит об изменениях в непустой базе.
Например, буквально вчера мне понадобилось грохнуть справочник и подставить вместо него в ссылающуюся таблицу обычное текстовое поле, взятое из поля справочника. Ни один инструмент анализа ни за что в жизни не «догадается», что это изменение было произведено именно так, а не как-то иначе, и, таким образом, сгенерированный им скрипт будет не работоспособен на базе с другим наполнением.

[maxidler]

Ну проблема-то в общем решаемая, только пользователям выполняющим генерацию миграций требуются права на создание временной базы.

[forketyfork]

Я имел ввиду, что она не решаема в общем виде автоматически средствами генерации миграций, без ручного написания дополнительного кода.
Речь ведь не только о том, чтобы сгенерировать скрипт различий, но и чтобы он корректно отрабатывал на любой базе, неважно, какие данные в ней уже есть. Простейший пример:

Было:

create table person (
  id bigint(20) not null,
  post_id bigint(20) not null,
  primary key(id),
  foreign key (fk_post) references post(id)
);

create table post (
  id bigint(20) not null,
  description varchar(20),
  primary key(id)
);

Стало:

create table person (
  id bigint(20) not null,
  post_description varchar(20),
  primary key(id)
);

В поле human.postDescription я переместил данные из поля post.description.

Написать скрипт, производящий такие изменения на существующей непустой базе — несложно. Сгенерировать такой скрипт автоматически на основании анализа двух схем — невозможно.

[maxidler]

С этим согласен, но это частный случай (в моей практике). У меня обычно добавляются поля и таблицы. При этом мне не удобно писать где-то код миграции, а затем запускать ее. Я люблю покопаться через консольный клиент MySQL, может быть даже несколько раз с перерывом в час-два, а затем, перед коммитом сгенерить миграцию.

[antirek]

А какие инструменты вы знаете?
Проблема есть, сам мучаюсь, но использую MySQL Workbench заставляя ее сравнивать структуры БД и находя различия.

[maxidler]

www.antonoff.info/development/mysql-migration-with-php-project Как-то так, если для ПыХаПэ…

[antirek]

спасибо, заценю.

[mustangostang]

посмотрите: code.google.com/p/mygrate/
Python, только для MySQL, правда.

[antirek]

Ну, мне хватит: ) спасибо.

[andreyoganesyan]

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

То есть флоу такой: внес изменения в JPA-модель -> сгенерил скрипты с разницей -> смигрировал базу. И так до бесконечности :)

Делает это плагин под названием JPA Buddy, выглядит вот так: