Hi Nathan,
I have this changeset:
If the table doesn’t exist and I run the changeset, everything works well. After that I can run a rollbackCount=1 (or rollbackCountSQL=1) and I get the expected result.
But if the table is there and I mark the changeset as ran, the rollback doesn’t work.
The same happens with the rest of things like, sql, sqlfile, etc… basically I have to manually change the exectype if I want to rollback.
Is this correct or should it rollback?
This was tested on: 2.0-RC2 an 2.0-RC3
Sorry for the slow reply. I’ve been thinking through the options, and i’m not sure what the best approach is. The change does get marked as MARKED_RAN, which the code is currently designed to ignore on rollback. The reason for that is because since the changeSet didn’t actually run, you may not actually want to roll it back at this point. if you did, than the earlier changeset that does create test_table would fail on rollback. But it should probably play into the rollback somehow.
In the end, I decided what made the most sense is to have your changeset roll back, but if it is not “executed”, the rollback should be a no-op. I committed that fix to trunk, does that seem like the most logical option?
Nathan
Hi Nathan… any decision you take is ok… I wanted to know what is the behaviour related to rollback on these cases:
Now I’m using the trunk code (rev 1703) and I have this error at the end of the rollback which was not present before:
[exec] Aug 13, 2010 12:22:34 PM liquibase.logging.jvm.JavaUtilLogger info
[exec] INFO: Successfully acquired change log lock
[exec] Aug 13, 2010 12:22:39 PM liquibase.logging.jvm.JavaUtilLogger info
[exec] INFO: Reading from DATABASECHANGELOG
[exec] Aug 13, 2010 12:22:39 PM liquibase.logging.jvm.JavaUtilLogger info
[exec] INFO: Rolling Back Changeset:install/warehouse/views/my_mview.xml::Create materialized view MY_VIEW::alexis::(Checksum: 2:1ebc2ee3cbe3f2402470f6979d9d4254)
[exec] Liquibase Update Failed: Unknown Reason. For more information, use the --logLevel flag)
[exec] Aug 13, 2010 12:22:39 PM liquibase.logging.jvm.JavaUtilLogger info
[exec] INFO: Successfully released change log lock
[exec] Aug 13, 2010 12:22:39 PM liquibase.logging.jvm.JavaUtilLogger info
[exec] INFO: Unknown Reason
[exec] java.lang.NullPointerException
[exec] at liquibase.changelog.filter.RanChangeSetFilter.getRanChangeSet(RanChangeSetFilter.java:17)
[exec] at liquibase.changelog.filter.AlreadyRanChangeSetFilter.accepts(AlreadyRanChangeSetFilter.java:15)
[exec] at liquibase.changelog.ChangeLogIterator.run(ChangeLogIterator.java:47)
[exec] at liquibase.Liquibase.rollback(Liquibase.java:245)
[exec] at liquibase.integration.commandline.Main.doMigration(Main.java:702)
[exec] at liquibase.integration.commandline.Main.main(Main.java:110)
Alexis, try the attached patch on your trunk and see if it removes your exception…
Thanks alwyn… that works and I don’t see the exception…
But I’ve just realized about something… In the rev 1703 the rollback behavior is different. Now the rollback is done based on the execution date and not based on the order that the changeset appears in the xml…
Was this changed? or I’m completely lost? 
Confirmed… I’m not lost… it works that way now
I will have a look at the code as soon as I can. I thought it was changed to be by orderexecuted column.
Btw. on your rollback question earlier. I don’t think its a good idea to set a changeset as RAN on fail, because then it wasn’t really executed and when rollback time comes it will try and rollback a change of which the SQL wasn’t executed so your rollback will definitively fail.
Looking at the code in trunk, the change sets are applied in order of date executed AND order executed, so it should be ok.
Yes, I did change the behavior lately so it is based on execution order (using both columns to ensure it is the correct order) not changelog order anymore. I think that makes more sense and will be less likely to break things. The reason it went by changelog order before was because execution time wasn’t exact enough and we would loose the correct order. I added the additional column in 2.0 but hadn’t changed the rollback order itself.
Nathan
Agree I think this is a better way of handling rollbacks
hi Nathan,
There is something that shoudn’t happen, if you have a RERAN exec type the rollback should be valid, e.g. with runOnChange=“true” (stored procedures, views, etc.)
I have this message and the rollback is skipped: [exec] – Did not actually execute. ExecType is liquibase.changelog.RanChangeSet@a3216ad0. Not rolling back
but it’s executed for sure
I changed it now so it will rollback reran statements. I’m not sure if there is a great way to handle that: if you have a stored proc that was re-ran to update it, what do you roll back to? We don’t have the previous value, it would actually drop it instead since that’s the inverse of creating.
This way makes a bit more sense, though, and you can always use the block to control what happens on rollback (like copying the old proc value into the rollback block before changing it)
Nathan
