2. Schema Migration
● Management of incremental, reversible changes to any relational database
schema
● Facilitate ways to fix mistakes and adapt to requirement changes
● Can be performed in newer or older versions
● Essential part of Software Evolution in today’s agile environment
3. Astonishment in Schema Migration
● Corrupt data that was written by old versions of the software and not cleaned
properly
● Implied dependencies in the data which no one knows about anymore
● People directly changing the database without using the designated tools /
scripts
● Bugs in the schema migration system
● Mistakes in assumptions how data should be migrated
4. Legacy Way (The Hard Way)
● DBA’s generally maintain two sets of scripts
○ Fresh installs
○ Upgrades
● Fresh Installs
○ Single script file will be used to handle single object in database
○ And separate scripts that will default data in master tables
● Upgrades
○ N-1 scripts would be maintained for a schema that has N versions
○ Will also include data migrations scripts for the said version X to Y
5. Snag In Hard Way
● How sure can we be that everything ran?
● If there’s a problem somewhere in the process, how do we rollback the
changes?
● Maintaining multiple scripts for various environments (Can I run some scripts
only for testing and not in production?)
6. Schema Change Management (SCM) Tool
● Every creation / change is defined in change log
● Start with create table in change log
● Followed by other DDL operations like adding or dropping column, index or
constraints in the table.
● SCM tools do support DML operations as well and can be part of change log
immediately after the DDL definitions
● SCM tools keeps track of what has or hasn’t been run and implement only the
new changes
● On a brand new DB SCM will run all the changes in change log.
7. Liquibase Features
● Update database to current version
● Rollback last X changes to database
● Rollback database changes to particular date/time or to a “tag”
● SQL for Database Updates and Rollbacks can be saved for manual review
● "Contexts" for including/excluding change sets to execute
● Database diff report & changelog generation
● Ability to create changelog to generate an existing database
● Database change documentation generation
● DBMS Check, user check, and SQL check preconditions
● Ability to split change log into multiple files for easier management
8. Features….
● Supports multiple developers
● Supports multiple formats (JSON, XML, YAML & SQL)
● Cluster safe database operations
● Can be run through the build process, embedded within the application or on
demand
● Out of the box support for 10+ DBs and 20+ DBs through the extensions
10. Change Log File
● Root of all changes are recorded in the
databaseChangeLog file.
● In Liquibase migrator runs, the parser
parses the databaseChangeLog tag.
● databaseChangeLog tag can have the
following sub tags
○ preConditions
○ Property
○ changeSet
○ include
<databaseChangeLog
xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ext="http://www.liquibase.org/xml/ns/dbchangelog-ext"
xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog
http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-3.1.xsd
http://www.liquibase.org/xml/ns/dbchangelog-ext
http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-ext.xsd">
</databaseChangeLog>
11. Precondition
● Controls the execution of an update based
on the state of the database.
● Can be part of changelog (global) or
changeset
● Conditional logics like or, and & not can
also be applied to preconditions.
<databaseChangeLog ………...>
<preConditions> //part of change log
<dbms type="oracle" />
<runningAs username="SYSTEM" />
</preConditions>
<changeSet id="1" author="bob">
<preConditions onFail="WARN"> //part of change set
<sqlCheck expectedResult="0">select count(*) from
oldtable</sqlCheck>
</preConditions>
<dropTable tableName="oldtable"/>
</changeSet>
</databaseChangeLog>
12. Property
● Liquibase allows dynamic substitution of
parameters in a changelog.
● Parameter values are looked up on the
following order:
○ Passed as a parameter to your Liquibase
runner
○ As a JVM system property
○ In the parameters block (<property> Tag)
of the changelog file.
<property name="clob.type" value="clob" dbms="oracle"/>
<property name="clob.type" value="longtext"
dbms="mysql"/>
<changeSet id="1" author="joe">
<createTable tableName="${table.name}">
<column name="id" type="int"/>
<column name="${column1.name}"
type="${clob.type}"/>
<column name="${column2.name}" type="int"/>
</createTable>
</changeSet>
13. Include
● Include tag allows us to break up change-
logs into more manageable pieces.
<databaseChangeLog
xmlns="http://www.liquibase.org/xml/ns/dbchangelog/1.9"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog/1.9
http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-1.9.xsd">
<include file="com/example/news/news.changelog.xml"/>
<include file="com/example/directory/directory.changelog.xml"/>
</databaseChangeLog>
14. ChangeSet
● Tag in which we can group database
changes/refactoring together
● Attributes available for changeSet are
○ Id → ChangeSet unique identifier
○ Author → Creator of the changeSet
○ dbms → the database on which the
specified changeset has to be run
○ runAlways → executes a changeSet every
time even if it has been run before
○ runOnChange → executes on the first time
and every time when there is a change in
changeSet
○ failOnError → specify if the migration has
to be failed on Error
● Available sub tags of changeSet are:
○ Comment → generally used for
descriptions
○ preConditions → Controls the execution of
an update based on the state of the
database.
○ Any Refactoring tags
○ Rollback → SQL statements or refactoring
tags that describe on how rollback needs
to taken place.
