Upgrading Client from 3.5.3 -> 3.6.2 results in numerous unwanted changes for updateToTag

General Discussion
1

I think what you are seeing is just liquibase updating the checksums for all of your changesets - the checksumming algorithm changed somewhat recently (I don’t recall the exact version number, but it was 3.6.x IIRC). So it won’t re-apply those changes to your schema, but it does need to update the checksum that is stored in the DATABASECHANGELOG table. 

Steve Donie
Principal Software Engineer
Datical, Inc. http://www.datical.com/

2

Since I’m a bit behind in updating sorry if this conversation happened I didn’t see it in a quick search of topics. Starting as a discussion… I’ll report proper via Jira tag if we figure it’s an actual bug.

I recently upgraded my client machine from version 3.5.3 -> 3.6.2 and today on first run of a new updateToTagSQL saw it generate a TON of potential change in that log file.  The actual change is pretty small (1 new column, remove 1 null constraint, add 1 index, add 1 foreign key) so I was really surprised to see an additional 1760 lines worth of change log!

Obv I can’t give access to our database so it’s hard to show the context but at least descriptively the file contained a full reset of all MD5SUMs: Running the following command (obfuscated)

liquibase --username=######## --password=############ --changeLogFile=changelog/catalogv7-master.yml --defaultsFile=cat7odb03.us-east-1.spsdev.in.liquibase.properties --outputFile=changelog/CAT-4860-dev03.sql updateToTagSQL version_1.13.5

UPDATE liquibase_own.DATABASECHANGELOG SET MD5SUM = NULL;

UPDATE liquibase_own.DATABASECHANGELOG SET MD5SUM = ‘8:a5d3a2e8a63df6ea750221412370ceb5’ WHERE ID = ‘7a-CAT-3274_rename_to_item_category_activity_trigger’ AND AUTHOR = ‘rwgrantham’ AND FILENAME = ‘changelog/catalogv7.oracle-CAT-3274.xml’;

…

(example… there were 719 of these one for each changelog in the change log database table)

Followed by another 1000 lines of actual changed with a pair of these next to each:

UPDATE liquibase_own.DATABASECHANGELOG SET MD5SUM = ‘8:a5d3a2e8a63df6ea750221412370ceb5’ WHERE ID = ‘7a-CAT-3274_rename_to_item_category_activity_trigger’ AND AUTHOR = ‘rwgrantham’ AND FILENAME = ‘changelog/catalogv7.oracle-CAT-3274.xml’;

(…changes…)

UPDATE liquibase_own.DATABASECHANGELOG SET DATEEXECUTED = SYSTIMESTAMP, DEPLOYMENT_ID = NULL, EXECTYPE = ‘RERAN’, MD5SUM = ‘8:a5d3a2e8a63df6ea750221412370ceb5’, ORDEREXECUTED = 388 WHERE ID = ‘7a-CAT-3274_rename_to_item_category_activity_trigger’ AND AUTHOR = ‘rwgrantham’ AND FILENAME = ‘changelog/catalogv7.oracle-CAT-3274.xml’;

SO: Why is it trying to “RERAN” all of my change sets (or maybe not all… I haven’t done a 1-1 comparison with the history).  ***Reverting to the previous version of the client (3.5.3) generated the short changelog I was expecting.

3

The checksum algorithm changed because a bug was discovered where sometimes the checksums were different when the line endings in an external file were different (i.e. when the file had either linux-style or windows-style line endings).

The issue was tracked with CORE-3069.

Steve Donie
Principal Software Engineer
Datical, Inc. http://www.datical.com/

4

I was presuming a checksum update and the first half of the UpdateSQL file lines up with updating all of the checksum entries in the changelog… the problem is the second half of the UpdateSQL that shows actual “SQL lines to be performed” rerunning all of those changesets. That isn’t good since not all update SQL was designed to be idempotent. Now if the UpdateSQL is not accurate and the actual Liquibase update won’t rerun those scripts that’s “fine-ish” but I still see that as a bug… 

I’m curious why liquibase would switch up checksum algos? This causes lots of issues for a large organization using the tool where any given client machine may be using some ? version of the Liquibase software so person A runs an update with 3.6.X and updates all of the checksums then person B runs another changeset with 3.5.X which now doesn’t like all of the updated checksums and does… something?  I’m sure there was a convincing reason to make this change but unlike previous updates to the software this effectively makes 3.5.X and 3.6.X incompatible which is frustrating at best…