liquibase.change

How changes are constructed and run when reading changelogs:

1. As the changelog handler gets to each element inside a changeSet, it passes the tag name to liquibase.change.ChangeFactory which looks through all the registered changes until it finds one with matching specified tag name
2. The ChangeFactory then constructs a new instance of the change
3. For each attribute in the XML node, reflection is used to call a corresponding set* method on the change class
4. The correct generateStatements(*) method is called for the current database

To implement a new change:

1. Create a new class that implements Change (normally extend AbstractChange)
2. Implement the abstract generateStatements(*) methods which return the correct SQL calls for each database
3. Implement the createMessage() method to create a descriptive message for logs and dialogs
4. Implement the createNode() method to generate an XML element based on the values in this change
5. Add the new class to the liquibase.change.ChangeFactory

Implementing automatic rollback support

The easiest way to allow automatic rollback support is by overriding the createInverses() method. If there are no corresponding inverse changes, you can override the generateRollbackStatements(*) and canRollBack() methods.

Notes for generated SQL:
Because migration and rollback scripts can be generated for execution at a different time, or against a different database, changes you implement cannot directly reference data in the database.