Use Liquibase to Safely Evolve Your Database Schema
最后更新于
这有帮助吗?
最后更新于
这有帮助吗?
转载:
In this quick tutorial, we'll make use of to evolve the database schema of a Java web application.
We're going to focus on a general Java app first, and we're also going to take a focused look at some interesting options available for Spring and Hibernate.
Very briefly, the core of using Liquibase is the changeLog
file – an XML file that keeps track of all changes that need to run to update the DB.
Let's start with the Maven dependency we need to add into our pom.xml:
We can also check if there's a newer version of liquibase-core .
Now, let's take a look at a simple changeLog file – this one only adds a column “address” to the table “users“:
Note how the change set is identified by an id and an author – to make sure it can be uniquely identified and only applied once.
Let's not see how to wire this into our application and make sure that it runs when the application starts up.
Our first option to run the changes on application startup is via a Spring bean. There are of course many other ways, but if we're dealing with a Spring application – this is a good, simple way to go:
Note how we're pointing it to a valid changeLog file that needs to exist on the classpath.
Then, all we need is to put our change log in “db/changelog/db.changelog-master.yaml” and Liquibase migrations will run automatically on startup.
We can change the default changelog file using the “liquibase.change-log” property – for example:
Sometimes, we may need to disable Liquibase migration's execution on startup.
The simplest option we have is to use a spring.liquibase.enabled
property. This way, all the remaining Liquibase configuration stays untouched.
Here's the example for Spring Boot 2:
For Spring Boot 1.x, we need to use a liquibase.enabled property:
changeLog
With a Maven PluginInstead of writing the changeLog file manually, we can use the Liquibase Maven plugin to generate one and save ourselves a lot of work.
Here are the changes to our pom.xml:
ChangeLog
From an Existing DatabaseWe can use the plugin to generate a changelog from an existing database:
Here are the liquibase properties:
The end result is a changeLog file that we can use either to create an initial DB schema or to populate data. Here's how that would look like for our example app:
ChangeLog
From Diff Between Two DatabasesWe can use the plugin to generate a changeLog file from the differences between two existing databases (for example development and production):
Here are the properties:
And here's a snippet of the generated changeLog:
This is a super powerful way to evolve our DB by – for example – allowing Hibernate to auto-generate a new schema for development, and then using that as a reference point against the old schema.
First, let's get the new plugin configured and using the right dependencies:
changeLog
from Diffs Between a Database and Persistence EntitiesNow, for the fun part. We can use this plugin to generate a changeLog file from the differences between an existing database (for example production) and our new persistence entities.
So – to make things simple – once an entity is modified, we can simply generate the changes against the old DB schema, getting a clean, powerful way to evolve our schema in production.
Here are the liquibase properties:
Note that the referenceUrl is using package scan, so the dialect parameter is required.
To generate a differential changeLog, simply install the plugin, then call the action from the JPA Structure panel. Select what source you want to compare (database, JPA entities, or Liquibase snapshot) with what target (database or Liquibase snapshot).
JPA Buddy will generate the *changeLog* as shown in the animation below:
Another advantage of JPA Buddy over the liquibase-hibernate plugin is the ability to override default mappings between Java and database types. Also, it works correctly with Hibernate custom types and JPA converters.
In this article, we illustrated several ways to use Liquibase and get to a safe and mature way of evolving and refactoring the DB schema of a Java app.
If we're using , there is no need to define a bean for Liquibase, but we still need to make sure we add the liquibase-core
dependency.
If the application uses Hibernate – we're going to take a look at a very useful way of generating the changeLog, which is .
If we're using a non-Hibernate ORM (e.g. EclipseLink or OpenJPA) or we don't want to add extra dependencies like the liquibase-hibernate plugin, we can use . This IntelliJ IDEA plugin integrates useful features of Liquibase into the IDE.
The implementation of all these examples and code snippets is available .