We have about 100 war-files running in the same Tomcat and connected to the same database. As these have been developed over some time, they use various versions of liquibase. When we made a new one and used the latest version of Liquibase, 3.6.0, it created all sorts of problems.
Once it loads, StandardChangeLogHistoryService.init() fetches the first non-null row it can find in DATABASECHANGELOG and checks the CheckSum-version. In our case, this will find version 7. Since the new war-module with Liquibase 3.6.0 is defined as version 8 (liquibase.change.CheckSum. CURRENT_CHECKSUM_ALGORITHM_VERSION) it will proceed to reset MD5SUM for all rows to NULL. It will then run it’s own changeset (currently only 1), leaving the remaining 1200+ rows with a NULL!
When any one of the existing war-files are loaded, they will find a lot of NULL’s, and rerun all changesets. This will fail if the changesets aren’t well enough protected with preconditions. (This is obviously a latent bug in our application, but new checksum-version is the only use case where it will be a problem.)
Occasionally, an application will happen to find the new version 8, and reset all MD5SUMs to NULL again, restarting the whole process.
The assumption that the current running instance of Liquibase is the only version running against a database is horrible. Changes to DATABASECHANGELOG must be done very carefully and with a clear eye towards backwards compatibility.
Also reported as CORE-3204.
M.