L'exécution de plusieurs déclarations de MySQL dans une transaction dans l'outil de migration mybatis

Question

J'utilise l'outil de migration mybatis pour maintenir le schéma à notre base de données, mais je vais avoir le problème suivant.

À l'heure actuelle, si nous utilisons plusieurs déclarations dans une migration, ils sont chaque passage dans une transaction séparée. Donc, si je veux modifier 2 tables (ou exécuter plusieurs instructions) dans le cadre d'une caractéristique et l'un d'eux brise, tout qui ont été lancé en premier doivent être manuellement est revenu. La migration de mybatis n'est toutefois marqué comme complet dans la table changelog si toutes les déclarations complété avec succès.

Ceci est vraiment frustrant car il n'y a aucun moyen de maintenir un état db constant si la migration entière n'est pas autonome.

Paramètres

ici est le cadre (pertinent) pour mybatis mygration pour notre base de données de test.

## 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

J'ai ajouté auto_commit = false, send_full_script = true et allowMultiQueries = true (à l'URL) pour tenter de maintenir la migration tout en une seule transaction.

Y a-t-il des paramètres d'URL mysql que je dois utiliser pour permettre cela? Est-ce seulement possible? On dirait qu'il devrait être. Peut-être que nous avons juste besoin de créer une migration pour chaque déclaration, mais qui semble excessive.

Exemple

Voici un autre exemple de clarification

Exemple migration 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 ....

Si je cours jusqu'à migrate échoue à cause de la ligne de b0rked; comme prévu. état Migrer montre la migration comme étant en attente comme prévu.

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

ma base de données a cependant les modifications appliquées! pas bon!

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)

Y at-il moyen d'empêcher cela? Dois-je simplement mettre chaque énoncé dans une migration et de passer? c'est là où je suis en ce moment.

Merci d'avance.

Answer 1

DML n'est jamais transactionnel - appliqué immédiatement. Il n'y a aucun moyen de rouler en arrière