Liquibase is one of the database version control tools that will stand multiple coders to rapidly manage database schema changes.
The basic idea of Liquibase is to provide an automated way of generating database migration scripts to describe your DB Engine how to go from “Schema X” to “Schema Y”. Here “Schema X” can be any state database and “Schema Y” can be any other database schema and to keep a version log of each of the changes in those scripts.
The feature that is probably most attractive in Liquibase is its capability to roll changes back and forward from a specific point — saving you from the need to know what was the final change/script you ran on a specific DB instance.
A changeset is a unit of change that Liquibase runs on a database. A changeset is uniquely tagged by both an
author and an
id attribute (
author:id), as well as the changelog file path. The id tag is only used as an identifier, it does not direct the order in that changes are run and does not have to be an integer. If you do not know or do not want to save the real author, use a placeholder value such as
UNKNOWN. To execute the changeset, you must have both
The changelog file is the source of all Liquibase changes. The changelog includes a sequential list of all database changes (changesets). Liquibase uses this changelog record to audit the database and enforce any changes that are not yet applied to the database. Changelogs can be in XML or JSON or YAML or SQL format and even mixing and matching distinct types of changelogs is also allowed.
The DATABASECHANGELOGLOCK table assures that only one instance of Liquibase is running at a time. The DATABASECHANGELOG_ACTIONS table follows the object state and the SQL statements run during the deployment.
This table is utilized by liquibase to track which changesets have been run. The table tracks each changeset as a row, specified by a combination of the “id”, “author”, and “filename” columns.
There is no primary key on the table. This is to avoid any database-specific constraints on key lengths. The “id”, “author”, and “filename” is unique across every row of the table.
We have to use the following dependency to run Liquibase.
<dependency> <groupId>org.liquibase</groupId> <artifactId>liquibase-maven-plugin</artifactId> <version>3.4.2</version> </dependency>
- Rollback:- The capability to undo changes is one of Liquibase’s most useful basic features. This can be taken out automatically or with the aid of a predefined SQL script. It is likely to use the automatically created rollback for commands like “create table”, “create view”, “add column”, and others. However, a few changes, like the “drop table” cannot be reversed. In that circumstances, rollback must be manually defined.
- Update/Rollback SQL Output:- Rather than executing updates or rollbacks directly against the database, you can generate the SQL that would be executed for inspection and/or manual execution.
- Future Rollback Output:- Before applying an update to a database, you can generate the SQL you would require to run in order to bring the database back to the state it is in now for inspection.
- ChangeLog and ChangeSet preconditions:- Preconditions can be added to the changeLog or individual changeSets to inspect the state of the database before trying to execute them
- DBDoc:- You are able to generate Javadoc-style documentation for your existing schema and its history.
- ChangeSet Contexts:- ChangeSets can be allocated “contexts” in which to run. Contexts are selected at runtime and can be utilized to have change sets that only run in test instances or other unique events.
- ChangeSet checksums:- Whenever a changeSet is executed, Liquibase stores a checksum and can fail or change execution if it notices a change between the original definition of a changeSet when it was run and the current definition.
- Diff Support:- Although Liquibase is built to use database comparisons for change management, there is help for it in Liquibase which is useful in many cases such as performing sanity checks between databases.
Advantages of Liquibase
- Liquibase supports tracking, managing, and applying database changes.
- Liquibase routes change independently rather than using a single version to keep multiple developers and/or code branches.
- The database history documentation can be generated using liquibase.
- It supports a wide range of databases.
- It has the capability to have the exact change description on multiple database types (ex:- If the application supports both MySQL and Postgres, we can have just one changelog and that changelog can be run against both database types).
- We can use the if/then logic while applying changes.
- It is open-source and free to use.
- Liquibase can run in 3-ways (by embedding it into the application, by embedding Liquibase into build tools, Run Liquibase to generate SQL for review).
- Liquibase can save you a lot of time and effort while migrating your databases.
- The community support for the Liquibase is excellent.
Reference Link:- https://en.wikipedia.org/wiki/Liquibase.