Reliable Database Migrations with Liquibase and Spring Boot

Table of contents

Reading Time: 2 minutes

In this blog, we look at database migrations with the very popular Liquibase database migration library and how you can use it in the context of a Spring Boot application.

Setting Up Liquibase in Spring Boot

By using default Spring Boot auto-configures Liquibase while we upload the Liquibase dependency to our construct document.
Spring Boot makes use of the primary DataSource to run Liquibase (i.e. the only annotated with @primary if there is a couple of). In case we need to apply a special DataSource we can mark that bean as @LiquibaseDataSource.
rather, we are able to set the spring. liquibase.[URL, user, password]properties, in order that spring creates a Datasource on its personal and uses it to automobile-configure Liquibase.

Through default, Spring Boot runs Liquibase database migrations mechanically on application startup.

It looks for a grasp changelog report in the folder DB/migration within the classpath with the name DB.changelog-master. YAML. If we need to use other Liquibase changelog codecs or use distinctive report naming conventions, we are able to configure the spring. liquibase. exchange-log application property to point to an exclusive grasp changelog record.

for example, to use db/migration/db.change-log.json because of the master changelog document, we set the following assets in application.yml:


liquibase.change-log=classpath:db/migration/db.changelog-master.xml

The master changelog can consist of different changelogs so that we can break up our modifications into logical steps.

Running Our First Database Migration

After setting the whole lot up, permit’s create our first database migration. We’ll create the database desk user_details in this example.

Let’s initiate a file with the term db.changelog-master.yaml and place it in src/main/resources/db/changelog:


<databaseChangeLog
   
   <include file="db/changelog/db.changelog-1.0.0.xml"/> 
                  
 </databaseChangeLog>

The master file is simply a cluster of includes that implies changelogs with the authentic changes.

Next, we build the changelog with the first real changeset and placed it into the file src/main/resources/db/changelog-yaml-example.yaml:

<databaseChangeLog>

<changeSet author="Krishna (generated)" id="1503460396396-1">

		<createTable tableName="employee_table">

			<column autoIncrement="true" name="employee_id" type="INT">
				<constraints primaryKey="true" />

			</column>

			<column name="email" type="VARCHAR(255)" />

			<column name="employee_name" type="VARCHAR(255)" />

			<column name="salary" type="DOUBLE" />

		</createTable>

	</changeSet>
	
	<changeSet author="Kishank (generated)" id="1503460396396-2">

		<createIndex indexName="EMAIL_INDEX" 

tableName="employee_table">

			<column name="email" />

		</createIndex>

	</changeSet>
	
	<changeSet id="1203460396356-3" author="Krishna (generated)">

		<insert tableName="employee_table">

			<column name="employee_name" value="Deepak"></column>

			<column name="email" value="rock.deep@yahoo.com"></column>
			<column name="salary" valueNumeric="85000.00"></column>
		</insert>

		<insert tableName="employee_table">

			<column name="employee_name" value="Manish"></column>

			<column name="email" value="manish.s@yahoo.com"></column>
			<column name="salary" valueNumeric="90000.00">

</column>
		</insert>

	</changeSet>

</databaseChangeLog>

Using Liquibase Context

As defined earlier, context can be used to control which exchange units have to run. let’s use this to add take a look at the information in the check and local environments:

<databaseChangeLog>

 <changeSet 

   author="Krishna Jaiswal" 

   id="1503460396396-1" 

   context="test or local">

   <loadUpdateData

     encoding="UTF-8"

     file="db/data/employee.csv"

     onlyUpdate="false"

     primaryKey="id"

     quotchar="'"

     separator=","

     tableName="emp_details">

   </loadUpdateData>

 </changeSet>

</databaseChangeLog>

We’re using the expression test or local so it runs for these contexts, but not in production.

So now we need to pass the context to Liquibase using the property spring.liquibase.contexts:

spring.profiles: docker

liquibase.parameters.textColumnType: TEXT

 contexts: test

Creating migration file

To create a new migration, you could run the make: migration Artisan command, and on the way bootstrap a new class to your Laravel utility, in the database/migrations folder.

 create table employee_table (

        employee_id integer not null auto_increment,

        email varchar(255),

        employee_name varchar(255),

        salary double precision,

        primary key (employee_id)

  );

Enabling Logging for Liquibase in Spring Boot

Allowing info degree logging for Liquibase will assist to peer the trade sets that Liquibase executes for the duration of the beginning of the application. It additionally enables us to identify that the utility has no longer commenced yet due to the fact it’s miles waiting to collect a changelog lock at some stage in the startup.
upload the subsequent application belongings in application.yml to allow info logs:

logging:

  level:

    "liquibase" : info

Conclusion

Liquibase enables automating database migrations, and Spring Boot makes it less complicated to apply Liquibase. This manual furnished info on a way to use Liquibase in the Spring Boot software and a few best practices.