| Interface all changes (refactorings) implement.
How changes are constructed and run when reading changelogs:
- 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
- The ChangeFactory then constructs a new instance of the change
- For each attribute in the XML node, reflection is used to call a corresponding set* method on the change class
- The correct generateStatements(*) method is called for the current database
To implement a new change:
- Create a new class that implements Change (normally extend AbstractChange)
- Implement the abstract generateStatements(*) methods which return the correct SQL calls for each database
- Implement the createMessage() method to create a descriptive message for logs and dialogs
- Implement the createNode() method to generate an XML element based on the values in this change
- 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. For example, you cannot implement a change that selects
all rows from a database and modifies them based on the primary keys you find because when the SQL is actually run, those rows may not longer
exist and/or new rows may have been added.
We chose the name "change" over "refactoring" because changes will sometimes change functionality whereas true refactoring will not.
See Also: ChangeFactory
See Also: Database |