databaseChangeLog = {
changeSet( .. ) {
grailsChange {
change {
... some gorm change
}
}
}
// here comes the failing change set
changeSet( .. ) {
... changes wich fails
}
}
We had such configuration in our project the problem here is that the first changeSet is marked as executed after first failing run, but the actual change was rolled back.
We fixed this explicitly opening newTransaction, like this:
databaseChangeLog = {
changeSet( .. ) {
grailsChange {
change {
GormEnitiy.withNewTransaction{ // <--- here is the magic
... some gorm change
}
}
}
}
// here comes the failing change set
changeSet( .. ) {
... changes wich fails
}
}
Taking into account the liquibase approach to the changeSets:
Liquibase attempts to execute each changeSet in a transaction that is committed at the end, or rolled back if there is an error.
Example:
We had such configuration in our project the problem here is that the first changeSet is marked as executed after first failing run, but the actual change was rolled back. We fixed this explicitly opening newTransaction, like this:
Taking into account the liquibase approach to the changeSets:
I think, it is better to fix this behaviour.