Page Comparison

LiquiBase Liquibase is designed to be flexible both in how it can be embedded and executed as well as how it behaves. As an Apache-licensed project, you are free to extend or integrate as you see fit and keep those changes private, or contribute them back to the community.  Have a suggestion on how to make the LiquiBase Liquibase Extensions Portal better?  Contact us.

Integration

LiquiBase Liquibase is integrated into systems primarily via the liquibase.LiquiBase Liquibase facade.  This object allows you to programatically control what LiquiBase does and/or create new execution methods beyond the Ant, Grails, command line, etc. options available in the core platform.  Available integration points include:

Extension

To the right is the path LiquiBase Liquibase takes from changelog to database.  Each stage can be modified to support new functionaly functionality or to modify existing logic. 

While LiquiBase Liquibase provides default implementations of all these steps, any one can be overridden with a custom subclass.  At each step in the process, LiquiBase Liquibase will search classes in known packages (liquibase core jar as well as all liquibase.ext.* package structures) for classes that implement the correct interfaces.  If it finds more than one that matches the correct interface, it will use a getPriority() method that is defined for each class.  The class with the higest highest priority is used.  The core LiquiBase Liquibase classes use priorities 1 and 5.

The basic path is:

1. A changelog file is passed to a changelog parser.  The correct changelog parser is selected based on the extension of the file.  
2. The changelog parser converts the original text into Change objects.  From this point on, there is no connection back to the original changelog file.  This allows changelog files to be written in any format that a changelog parser is written for.
3. The Change objects are ran, which generate Statement objects. The purpose of the Statement objects is to describe logically what type of statements will be needed to run for a change.  For example, a CreateTableChange object may return a CreateTableStatement.  A MergeTablesChange may return an AddColumnStatement, an UpdateStatement, and a DropTableStatement
4. For each Statement object, the correct SqlGenerator will be found that will create one or more Sql objects for the statement.  The number of Sql objects may depend on the database, for example MySQL will return a single "drop index" Sql object, but DB2 will return a "drop index" and a "reorganize table" statement.

Available extension points include: