Today I noticed that a large amount of changesets that were originally created by generateChangelog contained the mssql specific uniqueidentifier in stead of the neutral UUID type (can that be considered a bug?). I set out to fix this using a script. That would modify the changelog and put in validCheckSum tags for the modified changesets.
Here I ran into the trouble that I got validation errors after the script ‘fixed’ the changelog. Which was actually due to me misunderstanding validChecksum. It should contain the new checksum and not the old (guess to detect new modifications). It would be nice if the documentation could be a little bit more explicit about that. (And that the only way to obtain the new checksum is the output of liquibase.
Before I reached that conclusion I suspected the checksum calculation in liquibase. Especially since the md5sum column contained values ranging from 26 to 32, where I thought that md5sums were always fixed size (128 bit). I had a look at the code and googled a bit and it looks the algorithm that liquibase uses strips out the leading zero’s of individual bytes. Due to the use of Integer.toHexString().
More info at:
So I guess that’s a bug? I modified the algorithm in liquibase and with a small fix it generates real md5sums.
What is the best way to deal with large amounts of changesets that need to be fixed? I notice the error output cuts off at 25 so I can’t easily use the output of liquibase to feed my fix script with the new checksums (of course I can change the source but I guess more people might run into this).