Real-time monitoring for Liquibase database changes is here!

Meet the changeset

Liquibase uses changesets to represent a single change to your database. Here’s an example of a changeset to create a table. 

Each changeset has an “id” and “author” attribute which, along with the directory and file name of the changelog file, uniquely identify it.

<changeSet author=”Bob” id=”157”>
  <createTable tableName=”person”>
    <column autoIncrement=”true” name =”id” type=”INTEGER”>
      <constraints> nullable=”false” primaryKey=”true” primaryKeyName=”person_pkey”/>
    </column>
    <column name=”firstname” type=”VARCHAR(50)”/>
    <column name=”lastname” type=”VARCHAR(50)”>
      <constraints nullable=”false”/>
    </column>
    <column name=”state” type=”CHAR(2)”/>
    <column name=”username” type=”VARCHAR(8)”/>
    <column name=”column1” type=”VARCHAR(8)”/>
    <column name=”column2” type=”VARCHAR(8)”/>
  </createTable>
</changeSet>

 

--changeset Bob:157
CREATE TABLE public.person (
  id int4 NOT NULL GENERATED BY DEFAULT AS IDENTITY,
  firstname varchar (50) NULL,
  lastname varchar (50) NOT NULL,
  state bpchar (2) NULL,
  username varchar (8) NULL,
  column1 varchar(8) NULL,
  column2 varchar NULL,
  CONSTRAINT person_pkey PRIMARY KEY (id)
);

 

 

Designing changes

There are four different ways to define your changes: SQL, XML, YAML, and JSON formats. You can pick the format that is most comfortable for you to use.

Here’s an example of a changeset created in formatted SQL.

--changeset Bob:157
CREATE TABLE public.person (
  id int4 NOT NULL GENERATED BY DEFAULT AS IDENTITY,
  firstname varchar (50) NULL,
  lastname varchar (50) NOT NULL,
  state bpchar (2) NULL,
  username varchar (8) NULL,
  column1 varchar(8) NULL,
  column2 varchar NULL,
  CONSTRAINT person_pkey PRIMARY KEY (id)
);

 

 

Changelogs

Liquibase uses a changelog to explicitly list database changes in order. The changelog acts as a ledger of changes and contains a list of changesets (units of change) that Liquibase can execute on a database.

View documentation about the database changelog file and changeset tag for more information.

Tracking tables

Liquibase tracks which changeSets have or have not been deployed in a tracking table called a DATABASECHANGELOG. If your database does not already contain a tracking table, Liquibase will create it for you.

Liquibase also prevents conflicts from different callers’ updates on a secondary table called DATABASECHANGELOGLOCK.

View the documentation on DATABASECHANGELOG tables and DATABASECHANGELOCK tables for more information.

Changelogs and tracking tables allow Liquibase to:

  • Track and version database changes
    Users know which changes have been deployed to the database and which changes have not yet been deployed.
  • Deploy changes
    Liquibase compares the changelog against the tracking table and only deploys changes that have not been deployed to the database.

Liquibase also has advanced features such as contexts, labels, and preconditions to precisely control when and where a changeset is deployed.

Start using Liquibase with an existing database

Not starting with a blank database? No problem. Liquibase has a feature to generate a changelog to represent the current state of the database schema so you can start from an existing database.