Liquibase
Overview
Liquibase manages relational schema evolution as an ordered, checksum-tracked history of change sets.
Every JHipster-generated Spring Boot service in this organisation uses it: a master changelog <include>`s one file per logical change, and on start-up Liquibase applies any change set not yet recorded in the `DATABASECHANGELOG table.
That history model has one defining property — an applied change set is immutable. Most Liquibase pain experienced by the team traces back to that single rule being broken, usually by editing an old change set (or a CSV it loads) and breaking start-up for everyone who already ran it.
This module captures the conventions for authoring change sets, the immutability rule and the failure mode it causes, and the pattern that lets dev/test fixture data evolve freely without breaking that rule.
Topics
Changelog and change set conventions
Filename and id conventions, the standard file header, database-portable column types via declared <property> aliases, registering a file in the master changelog, and the pre-commit verification steps.
See Changelog and change set conventions for the full guide.
Change set immutability
The cardinal rule: never edit an applied change set. This page explains the two-phase validation that makes a single stale checksum abort an entire migration run — including unrelated schema changes — and the safe alternatives (append a new change set, or make a fixture loader re-runnable).
See Change set immutability for the rule and recovery paths.
Test data (fixtures) management
How to load, amend and reset dev/test fixture data without violating immutability: the loadUpdateData + runOnChange upsert pattern, when to edit a CSV in place versus append a delta, and the foreign-key ordering contract that a matching delete script must honour.
See Test data management for the pattern and the delete-script contract.