Changeset checksum validation failed with same md5sum value

General Discussion
1

Hi Everyone,

We are using liquibase-core 3.4.1 version. we are migrating the db changes through the  changelog sql file for postgres database. Below is the code for migration.

  liquibase = new liquibase.Liquibase(“db/<my_app_databasechange_log>.sql”, new ClassLoaderResourceAccessor(), database);

liquibase.update(new Contexts(), new LabelExpression());

we added few changesets to the my_app_databasechange_log.sql file and ran it in local, it worked fine. When we moved to another environment(QA) it is failing with below error for existing changeset which is 10 changesets above from the newly added changeset. 

The error is showing the same md5sum as what is there in the databasechangelog table.

lvl":“ERROR”,“msg”:"",“exception”:"liquibase.exception.ValidationFailedException: Validation Failed:\n     1 change sets check sum\n          db/<my_app_databasechange_log>.sql::<change_set_name>::o is now: 7:<old_md5sum>

Could you please help here.

Thanks

Sravan A

2

Hi Steve, 

I tried to print the checksum values current Changeset and old Changeset ( RanChangeset) for the changeset which are failed during the validation.

The RanChangeSet checksum value is different than what is existing in the detabasechangelog table md5sum value.

What could be the reason for printing the different value from what exists in database.

  validationFailedException.getInvalidMD5Sums().forEach(changeSet -> {

                         try {

                             finalDatabase.getRanChangeSetList().forEach((ranChangeSet -> {

                                     if(ranChangeSet.getId().equals(changeSet.getId())){

                                         logger.error("db changeset id:: " +ranChangeSet.getId() 

                                             + " checksum:: "+ranChangeSet.getLastCheckSum() + “\n current changeset id:: " + changeSet.getId()  +” current checksum:: "+ changeSet.generateCheckSum());

                                     }

                                 })

                             );

                         } catch (DatabaseException e1) {

                             e1.printStackTrace();

                         }

                     });

Thanks

Sravan A

3

Hi Steve,

Thanks for answering the question.

We did not update the version of liquibase version and it is 3.41. 

Below is the databasechangelog record for the existing changeset which is failing.

idmy_table_index_column1_alt current checksum:: 7:b7cfd7492431756ad5b4ee5ea769202f

4

Could you show the actual error message and the contents of the DATABASECHANGELOG table? Please remove any sensitive info from the logs if needed. 

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

5

What happened when you tried? Did it fail? I’m still not clear what your error is. 

The reason that you get that error message is that some changesets have been deployed to a database. At the time they were deployed, Liquibase calculated a checksum for each changeset. If you then run update again, Liquibase checks two things - whether each changeset in the changelog has been deployed before or not, which is does by comparing the changeset id, author, and path that in in the changelog to the entries in the DATABASECHANGELOG table. Liquibase also calculates a checksum for each changeset in the changelog again, and then compares that checksum to any that are in the DATABASECHANGELOG table. If they are different, that is an error.

Typically, this should only happen if the changeset has actually been changed between the first deploy and the second deploy. If you are certain that the changeset has NOT changed, then you can work around the problem by manually clearing the checksum column from that row, and Liquibase will just update the checksum - it won’t try to re-apply the changeset, but will just re-calculate the checksum. 

There are also cases where the checksum algorithm has changed - this has happened a few times in the lifetime history of Liquibase. The number with the colon preceeding the checksum is the version of the checksum algorithm. In your first post, the partial message you included showed a version of 7.

If you have recently updated the version of Liquibase you are using, that could be the issue. In that case, you can use the Liquibase clearChecksums command after you have verified that the changelog hasn’t been altered from what it should be, and then re-run the update command, and Liquibase will update the checksums as described above. 

Again, without a full description of what you did, and the full output of the errors, it is difficult to help more. 

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

6

Hi,
I’m suffering the same issue, because sometimes I use the version included in Oracle SQLCL, and others the Liquibase native.
But if I understand correctly, if the checksum algorithm is the same (in my case the version 8) it has not to happen.

Our test is:
SQLCL: LB GENSCHEMA → Generate a changeset / controller.xml file (it has only 4 files, a table, a sequence and 2 functions)
SQLCL: LB UPDATE (in another database) → Apply changeset and create Liquibase tables. It works fine.
LIQUIBASE: liquibase status (in the same database) → Error in checksum
Is it possible you have change the way that xml checksums are calculated. Is it a problem with versions?

--------- Output error ------------
liquibase status
####################################################
Starting Liquibase at 11:16:24 (version 4.6.1 #98 built at 2021-11-04 20:16+0000)
Liquibase Version: 4.6.1
Liquibase Community 4.6.1 by Liquibase

Unexpected error running Liquibase: Validation Failed:
4 change sets check sum
product_seq_sequence.xml::e9ec0fba162648f48121e9b24e9e768fd044079b::(DEMO_DEV)-Generated was: 8:cf8f0cd4cc24e38d31886c5da52bf94c but is now: 8:d41d8cd98f00b204e9800998ecf8427e
product_table.xml::71fa48be2a6f68d8e4986edf348f322f43952f6e::(DEMO_DEV)-Generated was: 8:57b9cf7d049700808c5c728d6c3e27fb but is now: 8:d41d8cd98f00b204e9800998ecf8427e
greeting_function.xml::d830191c8908c4972f1093b2376a62ad8341e784::(DEMO_DEV)-Generated was: 8:5f8f0a2b531ed8614e73277854991488 but is now: 8:d41d8cd98f00b204e9800998ecf8427e
productcount_function.xml::9fd0c3184ea4a1489c4e7124b5361afd21a478cf::(DEMO_DEV)-Generated was: 8:78bebb6f93ffc6a6591d96d7e7ac7674 but is now: 8:d41d8cd98f00b204e9800998ecf8427e

Versions:
Liquibase: 4.6.1
SQLcl: Versión 21.3.2.0 Production Versión interna: 21.3.2.287.1503

7

Hi @jmalbarran I’m not sure if the code for SQLcl provided by Oracle has been changed with regards to checksums or the way it is outputted. If you use sqlcl status for the last step in the recreation scenario, do the checksums match?

8

Hi
A colleague has tested, and if we use version Liquibase 4.4.2 the problem dissapears.

So, it seems that has been a change in the checksum calculation inside the liquibase product itself, between versions 4.4.2 and version 4.6.1.

Is it possible?