What is Change Type?
Definition
Each Change Type corresponds to a common structural operation: createTable, addColumn, dropColumn, addForeignKeyConstraint, and dozens of others. Because a Change Type describes what should happen rather than exactly how to write it in a given database's SQL dialect, the same ChangeSet can run against many different database platforms without being rewritten for each one. Change Types also make automatic rollback possible for many operations: dropping a column that was added, or dropping a table that was created, is a mechanical inverse a tool can generate without a person writing custom rollback SQL. Custom Change Types can be defined for operations that don't fit any built-in type, extending the same declarative model to organization-specific needs.
Why declarative Change Types matter
Writing raw SQL for every database change ties that change to one database's specific syntax, and a script written for one platform usually needs to be rewritten, sometimes significantly, to run against another. A declarative Change Type sidesteps that problem entirely: a ChangeSet that says to add a column, with a given type, to a given table, can be translated into the correct syntax for PostgreSQL, Oracle, SQL Server, or dozens of other platforms without a person maintaining separate versions. It also gives tooling something structured to reason about, which raw SQL, being free-form text, doesn't offer nearly as easily.
How Change Types work
A Change Type is essentially a template for a specific kind of operation, with parameters filling in the details: a table name, a column name and type, a constraint definition. When a ChangeSet runs, the underlying tool reads the Change Type and its parameters and generates the appropriate SQL for whichever database it's connected to. Many Change Types have a natural inverse operation, which is what allows automatic rollback generation: an addColumn Change Type can be reversed with a dropColumn operation without anyone writing that rollback by hand. Preconditions can also reference a Change Type's target object directly, checking it exists before the operation runs.
How Liquibase helps
Liquibase ships with a broad library of built-in Change Types covering the operations most schema changes actually need, and supports custom Change Types for anything organization-specific that doesn't fit a built-in one. Because Change Types are the same regardless of target platform, a team standardizing on Liquibase across multiple database engines writes one ChangeSet, not one per platform, and gets consistent rollback behavior and Policy Check coverage across all of them. This same declarative approach is also what allows a Policy Check to reason about a proposed change before it runs, since the check can inspect the Change Type and its parameters directly rather than trying to parse an arbitrary block of SQL.
