Database migration with Liquibase

Liquibase is an open source database independent library for managing database migration. Some of the important concepts that we need to understand before we can use liquibase are as follows.

1.DatabaseChangeLog: This is the file where we specify all the changes that should go into the database. The file can be XM, SQL, YAML or JSON format.

2.ChangeSet: This defines the individual changes or group of change that goes into database together. ChangeSet is identified by id and author.

3.PreCondition: As the name implies this ensures that database is in a particular state before executing the changeset.

4.Context: This ensure that changeSet runs only for specified environment.

Basic structure of a DatabaseChangeLog

Configuring Liquibase in the POM file.

Liquibase can be configured as plugin in the pom file. 

Steps for Database Migration:

Use case 1: This is the initial status of the database.

-  Only database is created but there is no database object yet created in the database. 

-  We have created the initial DatabaseChangeLog XML in our project. No changeSet other than the default is yet introduced in the DatabaseChangeLog.

1 . Run mvn liquibase:diff

This will create a changelog.xml file in the location as specified in the pom.

As there is no data in the database yet there will be no entry in this file.

2. Run mvn liquibase:updateSQL

This will create a sql file which have queries required to update the current version as specified in DatabaseChangeLog.

The initial DatabaseChangeLog has some default tables that needs to be created for liquibase such as DatabaseChangeLog and DatabaseChangeLoglock table.

The file will be created in the path we specify in the pom. 

Although the sql file will not be used to do an update in database but we can use this to verify what changes will actually get applied to the database when we run liquibase:update

3. Run  mvn liquibase:tag -Dliquibase.tag=initial_state

We will need to run this to create a rollback checkpoint in case we need to revert our changes.

4. Run mvn:update

This applies the DatabaseChangeLogs to the database. Once this run successfully you should be able to see the updated database.

5. Run mvn liquibase:diff

This will create a new changelog.xml file and it will have the database changes that has been made with previous update.

 Use case 2: We add changeSet to DatabaseChangeLog file

1. Make update to the DatabaseChangeLog to add new dataSet

2. Update the POM to add new version number. [Not mandatory,but recommended ]

3. Run liquibase:diff 

This will create changelog.xml file and will help us to keep a benchmark before we update the database. 

4. Run mvn liquibase:updateSQL

We will get the below file for the changeSet we have introduced.

5. Run mvn liquibase:tag -Dliquibase.tag=checkpoint_release_version_1

This will create a rollback checkpoint for this release

6. Run mvn liquibase:update

This will update the database with the new changes we introduced in the changeSet. We can see that address table is now present in the database.

Use Case 3: Rollback to a pre-existing state

Existing Database state. Two checkpoint defined.

1. Run mvn liquibase:rollback -Dliquibase.rollbackTag=checkpoint_release_version_2