Grails dbm-update & change_log 变更集：事务性与否？答案

【问题标题】：Grails dbm-update & change_log changesets: transactional or not?Grails dbm-update & change_log 变更集：事务性与否？
【发布时间】：2016-05-27 16:20:38
【问题描述】：

我的印象是迁移脚本中的变更集是事务性的，但我发现实际上它们不是。

对于这个最简单的例子，创建一个基本的变更集条目，可能如下：

changeSet(author: "some_email@server.com", id: "1-1", description: "An example changeset for a changelog.groovy.") {
    createTable(tableName: "table_name") {
        column(autoIncrement: "true", name: "id", type: "BIGINT") {
            constraints(nullable: "false", primaryKey: "true")
        }

        column(name: "version", type: "BIGINT") {
            constraints(nullable: "false")
        }

        column(name: "name", type: "VARCHAR(64)") {
            constraints(nullable: "false")
        }

        column(name: "name", type: "VARCHAR(64)") {
            constraints(nullable: "false")
        }

    }

}

现在，显然我们不能添加两个同名的列，所以这应该会失败 - 并回滚。但它不会回滚。创建了表并添加了第一列——尽管它是一个“坏”的变更集。

所以，问题是 -

1) 是 changelog.groovy 变更集事务吗？

2) grails dmb-update 是否应该以事务方式执行变更集？

3) 如果是这样，我们配置错误的是什么？

【问题讨论】：

你为什么会有这样的印象？他们不是。
因为有人告诉我他们是。哈哈！但是，好吧 - 他们不是。谢谢你。如果您添加答案，我会将其标记为完成。
它们不是事务性的问题是，如果大型变更集运行但失败，那么 dbm-rollback 也无法删除“坏”变更。因此，您必须手动更新表/列/FK 等，然后才能应用更正的 dbm-update。鉴于 Grails 的自动特性，这似乎不合常理。
主要问题是事务、回滚等主要是数据/DML 概念。一些数据库至少部分支持回滚结构/DDL 更改，但在一般情况下非常不切实际

标签： grails transactions grails-orm

【解决方案1】：

Grails 中的数据库迁移不是事务性的。如果您需要能够回滚失败的变更集，您必须自己编写回滚。

正如 Burt 指出的“主要问题是事务、回滚等主要是数据/DML 概念。一些数据库至少部分支持回滚结构/DDL 更改，但在一般情况下非常不切实际”。

【讨论】：