Комментарии 16
В ряде случаев (да, далеко не во всех) откат изменений вполне возможен. Поэтому, на мой взгляд, разработчики зря отказались от этой фичи, которая лично меня в dbdeploy время от времени выручает. Откаты БД, конечно же, автоматом никто не делает, но порой иметь на руках готовый для этого скрипт — архиполезно!
Статья будет неполной без упоминания ближайшего аналога — пакета liquibase, который позволяет описывать структуру объектов БД в виде XML-описания и, как следствие, позволяет делать откаты и многое другое.
www.liquibase.org/
www.liquibase.org/
Я решил ограничиться упоминанием сравнительной таблички различных решений (в том числе LiquiBase) на странице Flyway. От LiquiBase меня отпугнуло именно XML-описание изменений. Когда идёт речь о миграциях, то хочется быть «ближе к телу», т.е. к SQL. Меньше будет turnaround при написании и отладке скрипта, да и опыт показывает, что случается необходимость быстро накатить изменения скриптом, минуя систему миграции.
Кроме того, не вполне понимаю, как XML-формат связан с возможностью отката миграций. В случае Flyway это вполне обоснованное техническое решение by design, т.к. ничего не стоило бы включать в пакет изменений SQL-скрипт, восстанавливающий базу.
Кроме того, не вполне понимаю, как XML-формат связан с возможностью отката миграций. В случае Flyway это вполне обоснованное техническое решение by design, т.к. ничего не стоило бы включать в пакет изменений SQL-скрипт, восстанавливающий базу.
Тем, что в XML описывается суть изменений в виде мета-описания, а не сам SQL-скрипт, отягощенный подробностями реализации конкретной СУБД. Это позволяет описать изменение один раз — вместо двух SQL-скриптов: на создание изменений и на их откат (что увеличивает риск ошибки вдвое).
Но, если это необходимо Liquibase позволяет внедрить в описание и обычный SQL-скрипт.
И в XML нет ничего страшного.
Но, если это необходимо Liquibase позволяет внедрить в описание и обычный SQL-скрипт.
И в XML нет ничего страшного.
Я не имею ничего принципиального против XML. Но в том-то и дело, что при достаточно сложных изменениях (а они никогда не бывают простыми, особенно на непустой базе, когда требуется определить логику реструктуризации данных) без SQL-скрипта не обойтись. Стоит ли городить ради этого XML, если всё равно придётся предусматривать SQL-вкрапления.
Странно, но практически ни один инструмент миграции не позволяет делать следующее: Залезть ручками в БД, поменять все так, как нужно, а затем, перед коммитом, сгенерить скрипт различий со старой структурой. ПОЧЕМУ??? Я знаю только пару инструментов, позволяющих такое безобразие…
Думаю, это связано с тем, что эта задача достаточно сложная, и в общем виде нерешаемая, особенно когда речь заходит об изменениях в непустой базе.
Например, буквально вчера мне понадобилось грохнуть справочник и подставить вместо него в ссылающуюся таблицу обычное текстовое поле, взятое из поля справочника. Ни один инструмент анализа ни за что в жизни не «догадается», что это изменение было произведено именно так, а не как-то иначе, и, таким образом, сгенерированный им скрипт будет не работоспособен на базе с другим наполнением.
Например, буквально вчера мне понадобилось грохнуть справочник и подставить вместо него в ссылающуюся таблицу обычное текстовое поле, взятое из поля справочника. Ни один инструмент анализа ни за что в жизни не «догадается», что это изменение было произведено именно так, а не как-то иначе, и, таким образом, сгенерированный им скрипт будет не работоспособен на базе с другим наполнением.
Ну проблема-то в общем решаемая, только пользователям выполняющим генерацию миграций требуются права на создание временной базы.
Я имел ввиду, что она не решаема в общем виде автоматически средствами генерации миграций, без ручного написания дополнительного кода.
Речь ведь не только о том, чтобы сгенерировать скрипт различий, но и чтобы он корректно отрабатывал на любой базе, неважно, какие данные в ней уже есть. Простейший пример:
Было:
Стало:
В поле human.postDescription я переместил данные из поля post.description.
Написать скрипт, производящий такие изменения на существующей непустой базе — несложно. Сгенерировать такой скрипт автоматически на основании анализа двух схем — невозможно.
Речь ведь не только о том, чтобы сгенерировать скрипт различий, но и чтобы он корректно отрабатывал на любой базе, неважно, какие данные в ней уже есть. Простейший пример:
Было:
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.
Написать скрипт, производящий такие изменения на существующей непустой базе — несложно. Сгенерировать такой скрипт автоматически на основании анализа двух схем — невозможно.
С этим согласен, но это частный случай (в моей практике). У меня обычно добавляются поля и таблицы. При этом мне не удобно писать где-то код миграции, а затем запускать ее. Я люблю покопаться через консольный клиент MySQL, может быть даже несколько раз с перерывом в час-два, а затем, перед коммитом сгенерить миграцию.
А какие инструменты вы знаете?
Проблема есть, сам мучаюсь, но использую MySQL Workbench заставляя ее сравнивать структуры БД и находя различия.
Проблема есть, сам мучаюсь, но использую MySQL Workbench заставляя ее сравнивать структуры БД и находя различия.
www.antonoff.info/development/mysql-migration-with-php-project Как-то так, если для ПыХаПэ…
посмотрите: code.google.com/p/mygrate/
Python, только для MySQL, правда.
Python, только для MySQL, правда.
К вопросу об инструментах (да, вопрос очень старый, но статья до сих пор отлично гуглится :)
В идее можно генерировать дифференциальные Flyway скрипты, сравнивая модель и БД, одну БД и другую БД, а также модель со снапшотом этой же модели другой версии (из мастера, например)
То есть флоу такой: внес изменения в JPA-модель -> сгенерил скрипты с разницей -> смигрировал базу. И так до бесконечности :)
Делает это плагин под названием JPA Buddy, выглядит вот так:
В идее можно генерировать дифференциальные Flyway скрипты, сравнивая модель и БД, одну БД и другую БД, а также модель со снапшотом этой же модели другой версии (из мастера, например)
То есть флоу такой: внес изменения в JPA-модель -> сгенерил скрипты с разницей -> смигрировал базу. И так до бесконечности :)
Делает это плагин под названием JPA Buddy, выглядит вот так:
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Flyway: управление миграциями баз данных