Esecuzione di più istruzioni MySQL in una transazione nello strumento di migrazione di Mybatis

Question

Sto usando lo strumento di migrazione di Mybatis per mantenere lo schema nel nostro database, ma ho il seguente problema.

Attualmente, se utilizziamo più istruzioni in una migrazione sono ciascuna eseguita in una transazione separata. Quindi, se voglio modificare 2 tabelle (o eseguire più istruzioni) come parte di una funzione e una di queste pause, quelle che sono state eseguite per la prima volta devono essere riportate manualmente. La migrazione di Mybatis è tuttavia contrassegnata come completa nella tabella di Changelog se tutte le dichiarazioni completate correttamente.

Questo è davvero frustrante perché non c'è modo di mantenere uno stato DB costante se l'intera migrazione non è autonoma.

Impostazioni

Ecco l'impostazione (pertinente) per Mybatis Mygration per il nostro database di 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

Ho aggiunto auto_commit = false, send_full_script = true e permisemultiqueries = true (a URL) nel tentativo di mantenere l'intera migrazione in una transazione.

Ci sono dei parametri URL MySQL che devo utilizzare per consentire questo? È anche possibile? Sembra che dovrebbe essere. Forse dobbiamo solo creare una migrazione per ogni affermazione, ma sembra eccessivo.

Esempio

Ecco un ulteriore esempio per chiarimenti

Esempio di migrazione 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 ....

Se corro migro, fallisce a causa del b0rked; linea come previsto. Migrare lo stato mostra la migrazione in attesa di previsto.

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

Il mio database ha tuttavia le modifiche applicate! non bene!

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)

C'è un modo per prevenirlo? Dovrei semplicemente mettere ogni affermazione in una migrazione e andare avanti? Ecco dove sono adesso.

Grazie in anticipo.

Answer 1

DML non è mai transazionale - applicato immediatamente. Non c'è modo di farlo indietro