Liquibase pitfalls and fundamentals

In this post we’ll consider several of the Liquibase pitfalls and fundamentals, which you will hardly find in an introductory training or some how-to.

But prior delving into caveats, let’s consider at least some Liquibase alternatives.
If you consider Liquibase, you definitely have the necessity to store application / platform state somewhere.
Hence which alternatives do we have ? In such a case we potentially can:
– use Flyway;
– manage DB state and apply scripts via combination of some tool (e.g. Terraform or some cloud-specific tool like AWS Cloud Formation), bash / shell scripts and SQLs. Sure, this approach has it’s pros and cons and is thus a separate huge topic;
– discuss and elaborate the decision with DevOps and DB team, if you work on a platform and plan to have medium to large size DataBase and necessity to support it.

So here are some of the liquibase pitfalls, and fundamental concepts which can save you a lot of time and efforts:

• Strive to add reasonable constraints for to reinforce logical constraints wherever possible, and thus exclude probability of incorrect data inserts / updates
• Strive to define appropriate composite unique keys (a unique key made up of a combination of columns), which would enforce logical constraints and restrict incorrect data updates / inserts
• For tables, where data will be inserted dynamically, use auto-generated PrimaryKeys / IDs (GenerationType.IDENTITY)
• Liquibase has the notion named changelog, where it persists already applied changesets (scripts).
  You may need this for to fix data state, if it gets corrupted.
• Do not modify already applied changesets, rather create new ones, as Liquibase captures hashes for each changeset, and if you modify already “applied” changeset (script), liquibase deployment will start failing.
• Strive to keep data aligned across environments (DEV, TST and PROD), which would simplify further maintenance, i.e. always consequently apply changesets / scripts, starting from lower environments.
• Try not to use Database-specific things (like triggers, stored procedures) etc, as then most probably you risk to appear in a situation when you will have multiple changesets, at least for DB itself and for tests
• Do not use triggers and stored procedures for implementation of business logic, let’s consider another interesting post, why implementing business logic on DB side generally should be avoided (except those rare cases, where you really don’t have alternatives).

The above list doesn’t pretend to be full, but it may appear immensefully helpful, especially if you just start working with liquibase, and need to familiarize with major concepts, or need to understand major pitfalls.

If you consider whether to use e.g. Liquibase and delegate scripts management to application developers, or delegate DB management to separate DB team, it all depends on platform type you develop, DataBase size, requirements, and off course available engineers / resources.
If you use micro-service architecture, you could consider a hybrid mix of:
e.g. delegating database management itself to DB team, especially if you have some DBA(s),
and allow application developers to manage their database schemas (and appropriate tables) within the micro-services they develop via Liquibase.
Such an approach has plenty of advantages, e.g. when a team develops some feature, they’re best aware of related DDL / DML scripts, Database changes and so on.
It’s another good practice to create separate DB schema per a micro-service. A schema is usually asssociated with appropriate user, which will have read / write access to sub-set of tables.