But, based on this I would expect the ddl changes to be commited, but the change set would not be marked as run.
I observed some strange behavior that I was unable to reason about.
I had a change set that looked something like this:
some sql that fails
If I run this on mysql, everything is rolled back and the change set is not marked as run.
If I run this on Oracle, nothing is rolled back and the change set is marked as run.
I don’t know of any reason why it shouldn’t work. Are you rolling back by tag or by date or by number of changeSets?
Would it work better if you broke the changeSet up into three changesets, one with each change in it?
I didn’t issue a rollback, I expected the changeset to auto rollback since there was an error inside and I also expected it not to get marked as run.
I could break them into multiple change sets, but I wanted to get to the bottom of the problem, because it seems like a bug to me.
I see, sorry. The problem is because Oracle autocommits addColumn changes, so although liquibase attempts to run everything in a transaction that will rollback on error, the addColumn calls commit the transaction.
Because of that, it is usually best to have a single change per changeset unless you have a change that doesn’t autocommit on your database (most DDL statements on oracle).
I thought mysql autcommitted on add column as well, but perhaps not.
Yes, that is right. In either case the changeset should not have been marked as ran.
Any chance your "<span isn’t actually failing on oracle in a way that tells the JDBC driver about the failure?
Any updates or workarounds besides a single change per changeset?
I just found that Jira Issue https://liquibase.jira.com/browse/CORE-1110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel