Guidance Needed for Liquibase Upgrade (3.5.5 to 4.30.0) – Checksum Issues with Old ChangeSets

General Discussion
1

Hi Team,

While upgrading Liquibase Core from 3.5.5 to 4.30.0, I encountered several issues, particularly with managing changelog files across versions. Here’s a summary of my challenges and the specific guidance I’m seeking:

  1. Background:
  • Our process involves using the Liquibase zip and automating database upgrades by placing XML changelog files in a predefined path.
  • During the upgrade, I appreciated new validations like duplicate changesets and invalid database names.
  • However, I faced issues with changesets that contained multiple <sql> tags for different databases. These changesets made entries in the DATABASECHANGELOG table but didn’t execute. I resolved this by ensuring that each changeset contained only one change.
  1. Major Issue: Checksum Errors:
  • Older changesets, which we haven’t modified, are throwing checksum errors. For example:
<changeSet id="29957.20" author="david">
    <addForeignKeyConstraint 
        constraintName="config_fk" 
        baseColumnNames="pipe_id" 
        baseTableName="mdl_config" 
        referencedColumnNames="pipe_id" 
        referencedTableName="processor_pipe" 
        validate="true" />
</changeSet>

* There are ~40+ such cases. To mitigate client-side risks, I added `<validCheckSum>` entries for these changesets and got them working locally.
  • However, when running clearCheckSums and then update, I now see validation errors for 280+ changesets. Many follow this pattern:
<changeSet author="fonan" id="810.1">
    <sql dbms="h2, oracle" splitStatements="true" stripComments="true">
        TRUNCATE TABLE SERIES_SOURCE;
    </sql>
</changeSet>

The error seems to resolve if I move the dbms attribute from the <sql> tag to the <changeSet> level and update the changeset ID. However, these are old changesets, and modifying them isn’t feasible without significant risk.

  1. Key Question: Why does clearing checksums lead to these errors? Shouldn’t the old behavior simply recompute checksums during the update process? Even I saw the error with the next update without clearCheckSums.

  2. Request for Guidance:

  • Is there a more efficient approach to handle these issues while upgrading Liquibase?
  • How can I address these checksum errors without touching the old changesets or breaking execution?

Thanks in advance for your help!

2

I encountered similar issues and followed these steps to troubleshoot:

  1. Ran changeLogSync with Liquibase 4.30 before performing the database update with the new version.

  2. Executed update, and it worked fine.

  3. Ran update again to verify for any changes—no issues were reported, as nothing was updated.

  4. Used clearCheckSums, which set all MD5SUMs to null (as expected, common for fixing local mistakes or issues in DEV/QA environments). Just for testing purpose.

  5. Ran update again, but this time the same checksum error occurred for 270+ changesets, specifically where the dbms attribute is part of the SQL tag under the changeSet tag as given in the previous post.

Despite these steps, the issue persists.

It seems that Liquibase is using a different methodology for calculating checksums in the newer version, which is fine, but after back-to-back updates why is it behaving differently in checksum calculation?

Any insights or suggestions on resolving this would be appreciated!