Запуск нескольких операторов MySQL в одной транзакции в инструменте миграции Mybatis

Question

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

В настоящее время, если мы используем несколько операторов в миграции, каждый из них запускается в отдельной транзакции. Поэтому, если я хочу изменить 2 таблицы (или запустить несколько операторов) как часть функции, и один из них разрывается, все, что было выполнено сначала, должен быть возвращен вручную. Миграция Mybatis, однако, отмечена как полная в таблице Changelog только в том случае, если все операторы успешно завершены.

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

Настройки

Вот (актуальная) настройка Mybatis Mygration для нашей тестовой базы данных.

## JDBC connection properties.
driver=com.mysql.jdbc.Driver
url=jdbc:mysql://localhost:3306/gamealert_test?allowMultiQueries=true
username=gamealert
password=********

# If set to true, each statement is isolated
# in its own transaction.  Otherwise the entire
# script is executed in one transaction.
auto_commit=false

# This controls how statements are delimited.
# By default statements are delimited by an
# end of line semicolon.  Some databases may
# (e.g. MS SQL Server) may require a full line
# delimiter such as GO.
delimiter=;
full_line_delimiter=false

# This ignores the line delimiters and
# simply sends the entire script at once.
# Use with JDBC drivers that can accept large
# blocks of delimited text at once.
send_full_script=true

Я добавил auto_commit = false, send_full_script = true и AllingMultiqueries = true (TO URL) в попытке сохранить всю миграцию в одной транзакции.

Существуют ли какие -нибудь параметры URL MySQL, которые мне нужно использовать, чтобы разрешить это? Это вообще возможно? Похоже, это должно быть. Может быть, нам просто нужно создать одну миграцию для каждого утверждения, но это кажется чрезмерным.

Пример

Вот еще один пример для разъяснения

Пример миграции 20110318154857_fix_daily_sales:

--// fix daily_sales naming
-- Migration SQL that makes the change goes here.

ALTER TABLE `daily_sales` CHANGE COLUMN `storeId` `store_id` INT(10) UNSIGNED NOT NULL;

b0rked;

--//@UNDO
-- SQL to undo the change goes here.
... undo sql here ....

Если я бегу, мигрирую, это не удается из -за b0rked; линия, как и ожидалось. Статус миграции показывает миграцию как ожидаемую, как и ожидалось.

20110318130407 2011-03-18 17:06:24 create changelog
20110318144341 2011-03-18 17:06:30 fix schedule naming
20110318154857    ...pending...    fix daily sales naming

Однако моя база данных имеет изменения! нехорошо!

describe daily_sales;
+-----------+------------------+------+-----+---------+-------+
| Field     | Type             | Null | Key | Default | Extra |
+-----------+------------------+------+-----+---------+-------+
| store_id  | int(10) unsigned | NO   | PRI | NULL    |       |
| sale_date | date             | NO   | PRI | NULL    |       |
| type_id   | int(10) unsigned | NO   | PRI | NULL    |       |
| tokens    | int(10) unsigned | NO   |     | 0       |       |
| dollars   | double           | NO   |     | 0       |       |
+-----------+------------------+------+-----+---------+-------+
5 rows in set (0.00 sec)

Есть ли способ предотвратить это? Должен ли я просто поместить каждое заявление в миграцию и двигаться дальше? Вот где я сейчас.

Заранее спасибо.

Answer 1

DML никогда не является транзакционным - применяется немедленно. Нет способа отказаться назад