07.06.2016 | Steffen Mall | comment icon 1 Comment

Basics of continuous database integration with liquibase

When implementing and deploying a new version of an application simple and fast refactoring of your database model is one of the most important things in order to implement flexible business requirements. Liquibase supports tracking, managing and applying database schema changes. In past projects a few months ago the handling with database changes respectively continuous database integration was always a topic. In my opinion there are various approaches which are not optimal. Here are some pros and cons of classical approaches and an introduction into liquibase.

Pros and cons of classical approaches

Database integration by SQL script:

add high variable control
forbidden no automated respectively only conditionally version management of your database schema changes
forbidden no automated execution of your scripts / requires separate implementation
forbidden dependency to operation team
forbidden difficult to handle or support different database vendors

Database integration by JPA (e.g. with hibernate.hbm2ddl.auto):

add tight coupling to implementation
add dialect resolver for different database vendors
forbidden only conditionally version management of your changes
forbidden refactoring with data changes difficult or impossible
forbidden less variable control

In some cases this may work for you, but it can easily destroy data model and underlying data. It depends on how the database gets from one state to the new state, this information must be defined.

Database integration by own engine:

forbidden Why? You should better focus on business logic instead of maintaining your own written stuff – this is the entrance to the gates of hell.

Therefore my one and only solution is liquibase.

Major Concept of liquibase

The major concept of liquibase is to store all changes in a text based file. The change information can apply to different databases, for example local development or other infrastructure stages like production. Liquibase uses a changeset concept to group database changes and provides a version control.

Basics of liquibase

The root of all liquibase changes is a db.change.log file. The file can be defined in different formats – my preferred format is xml. Let us start with some examples to feel the power and simplicity of liquibase.

Listing 1:
To start create empty db.changelog.xml.

Listing 2: Add first changeset and create a simple table with two columns.

Listing 3: Simply add a column.

Listing 4: Drop a column.

Listing 5: More complex refactoring – add not null constraint to existing column and update existing values to ensure validity of table.

There is a big variety of features which are well documented, check http://www.liquibase.org/documentation/index.html for more details. Use the built-in search to search for specific scenarios.

Finally apply the liquibase file to your database. There are several ways to apply / run the file. My preferred one is the CDI integration in order to ensure an automated process. Just provide a liquibase specific producer to do this. On each deployment liquibase checks which changeset is relevant for execution. With this power you are able to maintain your database with every new release and you are able to start with a new environmet from scratch.

Listing 6:
Add liquibase-cdi dependency to your pom.xml.

Listing 7: Example of liquibase CDI producer.
The location of our liquibase file is src\main\resources\db.changelog.xml.

The CDI configuration will cause liquibase to run automatically when the CDI container is initialized. It will load db-changelog.xml from the classpath and apply it against your datasource.

Let’s see what happens:

These were the beginnings and basics of liquibase. Just try it out for yourself. For advanced information please follow future blog posts.

java ee jpa liquibase
  1. Best practice in order to use liquibase and hibernate JPA with in memory h2 database in JUnit together with mockito - Exxeta Blog
    Posted on
    […] addition to my first liquibase post “basics of continuous database integration with liquibase” I give you some best practice in order […]

Leave a Comment