1. Введение
В этом кратком руководстве мы рассмотрим несколько способов отката миграции с помощью Flyway.
2. Моделирование отката с помощью миграции
В этом разделе мы откатим нашу базу данных, используя стандартный файл миграции.
В наших примерах мы будем использовать версию Flyway для командной строки. Однако основные принципы в равной степени применимы и к другим форматам, таким как основной API, подключаемый модуль Maven и т. д.
2.1. Создать миграцию
Во-первых, давайте добавим новую таблицу книг в нашу базу данных. Для этого мы создадим файл миграции с именем V1_0__create_book_table.sql :
create table book (
id numeric,
title varchar(128),
author varchar(256),
constraint pk_book primary key (id)
);
Во-вторых, применим миграцию:
./flyway migrate
2.2. Имитация отката
Затем, в какой-то момент, скажем, нам нужно отменить последнюю миграцию.
Чтобы восстановить базу данных до того, как была создана таблица book , давайте создадим миграцию с именем V2_0__drop_table_book.sql :
drop table book;
Далее применим миграцию:
./flyway migrate
Наконец, мы можем проверить историю всех миграций, используя:
./flyway info
что дает нам следующий вывод:
+-----------+---------+-------------------+------+---------------------+---------+
| Category | Version | Description | Type | Installed On | State |
+-----------+---------+-------------------+------+---------------------+---------+
| Versioned | 1.0 | create book table | SQL | 2020-08-29 16:07:43 | Success |
| Versioned | 2.0 | drop table book | SQL | 2020-08-29 16:08:15 | Success |
+-----------+---------+-------------------+------+---------------------+---------+
Обратите внимание, что наша вторая миграция прошла успешно.
Что касается Flyway, второй файл миграции — это просто еще одна стандартная миграция. Фактическое восстановление базы данных до предыдущей версии полностью выполняется с помощью SQL. Например, в нашем случае SQL удаления таблицы противоположен первой миграции, которая создает таблицу.
Используя этот метод, контрольный журнал не показывает нам, что вторая миграция связана с первой , поскольку они имеют разные номера версий. Чтобы получить такой контрольный журнал, нам нужно использовать Flyway Undo.
3. Использование отмены Flyway
Во-первых, важно отметить, что Flyway Undo является коммерческой функцией Flyway и недоступна в Community Edition. Поэтому для использования этой функции нам понадобится Pro Edition или Enterprise Edition.
3.1. Создать файлы миграции
Во-первых, давайте создадим файл миграции с именем V1_0__create_book_table.sql :
create table book (
id numeric,
title varchar(128),
author varchar(256),
constraint pk_book primary key (id)
);
Во-вторых, давайте создадим соответствующий файл отмены миграции U1_0__create_book_table.sql :
drop table book;
В нашей отмене миграции обратите внимание на префикс имени файла «U» по сравнению с обычным префиксом миграции «V». Кроме того, в наших файлах отмены миграции мы пишем SQL, который отменяет изменения соответствующего файла миграции . В нашем случае мы удаляем таблицу, созданную при обычной миграции.
3.2. Применить миграции
Далее давайте проверим текущее состояние миграций:
./flyway -pro info
Это дает нам следующий результат:
+-----------+---------+-------------------+------+--------------+---------+----------+
| Category | Version | Description | Type | Installed On | State | Undoable |
+-----------+---------+-------------------+------+--------------+---------+----------+
| Versioned | 1.0 | create book table | SQL | | Pending | Yes |
+-----------+---------+-------------------+------+--------------+---------+----------+
Обратите внимание на последний столбец Undoable , который указывает, что Flyway обнаружил файл отмены миграции, сопровождающий наш обычный файл миграции.
Далее, давайте применим наши миграции:
./flyway migrate
Когда он завершится, наши миграции будут завершены, и в нашей схеме появится новая таблица book:
List of relations
Schema | Name | Type | Owner
--------+-----------------------+-------+----------
public | book | table | foreach
public | flyway_schema_history | table | foreach
(2 rows)
3.3. Откат последней миграции
Наконец, давайте отменим последнюю миграцию с помощью командной строки:
./flyway -pro undo
После успешного выполнения команды мы можем снова проверить статус миграции:
./flyway -pro info
что дает нам следующий вывод:
+-----------+---------+-------------------+----------+---------------------+---------+----------+
| Category | Version | Description | Type | Installed On | State | Undoable |
+-----------+---------+-------------------+----------+---------------------+---------+----------+
| Versioned | 1.0 | create book table | SQL | 2020-08-22 15:48:00 | Undone | |
| Undo | 1.0 | create book table | UNDO_SQL | 2020-08-22 15:49:47 | Success | |
| Versioned | 1.0 | create book table | SQL | | Pending | Yes |
+-----------+---------+-------------------+----------+---------------------+---------+----------+
Обратите внимание, что отмена прошла успешно, и первая миграция снова стала отложенной. Кроме того, в отличие от первого метода, в журнале аудита четко отображаются миграции, которые были отменены.
Хотя Flyway Undo может быть полезен, он предполагает, что вся миграция прошла успешно. Например, он может работать не так, как ожидалось, если миграция не выполняется на полпути.
4. Вывод
В этом кратком руководстве мы рассмотрели восстановление нашей базы данных с помощью стандартной миграции. Мы также рассмотрели официальный способ отката миграций с помощью Flyway Undo. Как обычно, весь наш код, относящийся к этому руководству, можно найти на GitHub.