I think that the term ‘rollback’ as used by Liquibase is giving a mistaken idea about how it functions. This is especially true for people who work with databases all the time and think of rollback in a database transaction.
Liquibase does not automatically roll back changes made during a deploy if there was an error. Rather, it can roll a database back to a previous schema state when you ask it to. In some cases, it can do that without you explicitly saying how to do the rollback.
It would be better to think of the rollback command in Liquibase as ‘undo deploys’ rather than a transactional rollback.
Steve Donie
Principal Software Engineer
Datical, Inc. http://www.datical.com/
If you continue with Liquibase, the best way to deal with this is to fix your changelog so that the problem doesn’t happen again. Unfortunately, when the scenario you described happens, the database can be left in an uncertain state, which is why it is considered a ‘best practice’ to limit changesets to a single change.
The recommendation when using Liquibase is to test your database deploy process in development, then in test, then in staging, then in production. If you are disciplined about not allowing changes in the different environments except through Liquibase, by the time you get out of development you will typically have found the issues like this and when you get to later environments deploying your database changes becomes completely routine.
You can also use preconditions to check whether some condition is true or not, and then only apply the changeset in one of those cases. I feel like that is a ‘code smell’ that is best avoided if possible.
If you would consider looking at Datical DB, then we have written extensions to Liquibase that make these kinds of workflows more automated. For example, we have a command “deployOrAutoRollback” that does what you are looking for. We have also extended Liquibase to support more database object types, a rules engine that can help automate the checks your DBAs might be doing, and many other features.
Steve Donie
Principal Software Engineer
Datical, Inc. http://www.datical.com/
Thanks Steve,
I think I see what you mean now so we can say for two changesets to tell them to simply rollback and they will know how to do this e.g. if createTable was used? That still sounds useful perhaps the command name should be called “undo” rather than rollback then.
However how would you also best handle the scenario I mentioned e.g. creation of a table succeeds in one part of the changeset and the second table creation fails?
