Hello! Fairly new to Liquibase fun, and first post so apologies if this is a duplicate and/or a silly question…!
I’m looking into defining rollback steps for our changes, and writing better guidance to my team. I note on here: Liquibase Rollback Workflow it says the following:
Many Change Types such as create table , rename column , and add column can automatically create rollback statements. If your changelog contains only statements that fit into this category, your rollback commands will be generated automatically.
My question is, how do I find out which change types support the automatic rollback statements? I can’t see any lists on the docs, or any notes made on the pages for e.g. createTable saying it supports it. Or is it just those three listed as examples? Or is this more complicated than I am initially understanding.
I was hoping to provide my team with “try and use these change types primarily, and if using others, need to write a rollback command too” that we can then check against at peer review…
I looked at the documentation and think this is the important part of the statement:
Other Change Types such as drop table and insert data have no corresponding rollback commands that can be automatically generated. In these cases, and cases where you want to override the default generated rollback commands, you can specify the rollback commands via the tag within the changeset tag.
So, basically sql commands that can deterministically be rolled back. Created a table? Sure, I can drop that table on a rollback. However, going the other way around, Dropped a table? Uh, I don’t know how to generate the corresponding state based table that was deleted…is the way I think of it.
I don’t think a full list exists, because the list would also probably have to be tested against all different db platforms that liquibase supports. I am happy to help get your experience documented though. If you want, please share commands you verify to autorollback and the db platform used.
That’s really helpful, thanks for the quick reply! So we should assume the logical simple changes that have a clear obvious reverse option would probably be automated, and can verify that using the futureRollbackSQL command. Then if any don’t, we have to fill in the gaps for these.
We’re using Oracle here, I’ll be sure to come back with our experiences when we’ve tested out the rollback steps more - if that will help!
Hey @phorrock! Oracle is one of the more popular db platforms used in the Liquibase community, so sharing your experiences will be greatly appreciated.
You nailed it on how to test, most should be obvious but getting it into documentation would be best, we even have a hacktober hackathon project to contribute to our docs (only if interested):
