Many refactorings such as “create table”, “rename column”, and “add column” can automatically create rollback statements. If your change log contains only statements that fit into this category, your rollback commands will be generated automatically.
Other refactorings 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
|nested tags||Standard Liquibase change tags to generate rollback statements|
|tag text||SQL to run to rollback this change|
|changeSetId||Id of changeset to rerun in order to rollback this change. Example: for rolling back a dropTable change, reference the changeSet that created the table.|
|changeSetAuthor||Author of changeset to rerun in order to rollback this change|
Many change tags do not need a rollback tag. They can be generated from the update statement.
Standard change tags can be used in a
Multiple statements can be included in one
<rollback> tag. Multiple rollback tags can be specified in one changeSet.
A rollback tag can reference the changeSet the originally created a statement.
Rollback tags can be empty if no rollback is possible/needed
You can specify what changes to rollback in three ways:
Specifying a tag to rollback to will roll back all change-sets that were executed against the target database after the given tag was applied. See the “command line” documentation for how to tag your database.
You can specify the number of change-sets to rollback.
You can specify the date to roll back to.
Liquibase has three modes for managing rollbacks:
The rollback commands can be executed directly against the target database. If any changes cannot be rolled back, you will be notified and none of the changes will roll back.
Rather than actually updating the database, the SQL required to roll back the database can be generated. This is useful if you want to preview what rollback commands will be executed before they are actually run.
This mode is designed to allow you to generate a rollback script at the same time you generate your migration script. It allows you to take an updated application and generate both the SQL to update the database to the new version as well as the SQL to bring that new version back to the current version if needed. This functionality is very useful when a DBA wants to control SQL going into the database, as well as for applications that require rollback documentation for internal and/or “SOX-compliant” processes. You do not need to specify a rollback date, tag, or count in this mode.