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.
3. Использование Отмены Пролета
Во-первых, важно отметить, что Отмена Flyway является коммерческой функцией Flyway и недоступна в версии сообщества. Поэтому для использования этой функции нам понадобится либо версия Pro, либо корпоративная версия.
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 | +-----------+---------+-------------------+------+--------------+---------+----------+
Обратите внимание на последнюю колонку Отменить , которая указывает , что Flyway обнаружил файл отмены переноса, который сопровождает наш обычный файл переноса.
Далее давайте применим наши миграции:
./flyway migrate
Когда он завершится, наши миграции будут завершены, и в нашей схеме появится новая таблица книг:
List of relations Schema | Name | Type | Owner --------+-----------------------+-------+---------- public | book | table | baeldung public | flyway_schema_history | table | baeldung (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 может быть полезной, предполагается, что вся миграция прошла успешно. Например, это может работать не так, как ожидалось, если миграция завершится неудачей на полпути.
4. Заключение
В этом коротком руководстве мы рассмотрели восстановление нашей базы данных с помощью стандартной миграции. Мы также рассмотрели официальный способ отката миграций с помощью отмены Flyway. Как обычно, весь наш код, относящийся к этому учебнику, можно найти на GitHub.