Make Checksum-Update downwards compatible

[robert-gdv]

Search first

• I searched and no similar issues were found

Description

We updated our Spring Boot Server from Liquibase 4.20.0 to 4.24.0. There was no new db.changelog file. So this update wasn't expected to have modified the DB.
But apparently the checksum algorithm was changed to a checksum starting with 9: instead of 8:.

Due to other issues, we had to rollback and deploy the previous version of the server.
But it failed to start, because of a lot of checksum issues. I assume, that it just didn't know the 9: checksum.

In #1681 (comment) @molivasdat suggested two solutions:

1. to use validCheckSum: Must be followed backwards for all changesets in foresight. But we just trained our devs to NOT change changesets.
2. Clear checksums in DB: You can do that easily in a test or dev-System. But in production system it is not that easy to get the permission to modify the DB in a manual untested way. Especially with time pressure.

Steps To Reproduce

1. Write a Spring Boot server application with spring 3.1.10, an oracle DB and a changelog. It will use Liquibase 4.20.0. Let's call it version X.
2. Deploy Version X so that it's liquibase changelog is applied.
3. Update the application dependency to spring 3.2.3. It will use liquibase 4.24.0. No changelog is touched. Let's call it version Y.
4. Deploy Version Y and let liquibase run automatically. This shouldn't modify the DB, but update only the checksums.
5. Deploy Version X. You will receive a warning about checksum issues.

Expected/Desired Behavior

1. Recalculated changeset-checksums should not overwrite old checksums but append a list of existing checksums.
   E.g. liquibase 4.20.0 writes

changelogX   8:abcdef

and liquibase 4.24.0 should add

changelogX   8:abcdef
changelogX   9:345abc

2. When verifying the checksum, liquibase should check only the highest existing checksum version it knows:
   liquibase 4.20.0 (after server version rollback) should check 8:abcdef and ignore 9:345abc.

3. If only unknown checksum versions are available for a changeset, then I would expect liquibase to behave as it does now (check validCheckSum, fail)

Liquibase Version

4.24.0

Database Vendor & Version

com.oracle.database.jdbc:ojdbc10 v19.22.0.0

Liquibase Integration

spring boot

Liquibase Extensions

No response

OS and/or Infrastructure Type/Provider

RedHat

Additional Context

I don't know anything about the internal behaviour of liquibase. So some wording/behaviour might be wrong. I would be glad if you try to understand the general issue and feature request.

Are you willing to submit a PR?

• I'm willing to submit a PR (Thank you!)

[kevin-atx]

@robert-gdv - I have an update for you from the engineering team:

Liquibase now manages both the v8 and v9 checksum versions. Moving forward, this will not be a problem. If you need to revert back to a version before 4.24.0, then you will need to use clearChecksums.

[robert-gdv]

@kevin-atx : Thank you for your information. Although it is not totally clear. Are you informing me about a new feature or do you want to tell me how to solve the issue with the current system?

Downwards compatiblity was already working. AFAIK the checksums were simply updated to a newer version.
But is the current version upwards-compatible to a future v10 checksum?
Can v9 checksums be calculated and stored without deleting v8 checksums from the DB?
Will the roundtrip 4.20.0 -> 4.x.0 (x > 24) -> 4.20.0 require a manual operation on the DB?

My issue is that manual intervention with the DB is in production more costly to organize. Only very few have the permission to modify the DB. And because of the checksum-rewrite a liquibase minor version update requires a DB-Admin support.

[kirangodishala]

We are facing similar issue - spinnaker/spinnaker#6941
We upgraded liquibase from 3.10.3 to 4.24.0 in Spinnaker and started seeing errors like this - 8:f0bfebd55de9168e38a8ef9c7217c610 but is now: 8:d41d8cd98f00b204e9800998ecf8427e.
Manual overwriting of md5sum is not an option in production.

[robert-gdv]

@kirangodishala : You made quite a Version jump. This enhancement is about how different versions of checksums are stored.
When you seach the issues, you can find some entries where the same checksum version 8 was recalculated with a different result. e.g. #4156

[kirangodishala]

@robert-gdv - It's a big leap but we verified with the versions in between, and the checksum issue started with 4.23.0. Probably I need to raise a new issue then?