I understand that the content of a changeset is used when the md5sum is calculated.
However, I was trying to get a database (D1) into phase with another database (D2) by copying the records in DATABASECHANGELOG that I do not want to be run in the D1 database. However, when I run liquibase updateSQL against D1 I get checksum error on changesets not changed. Is the JDBC url involved when calculating the MD5SUM value?
I solved it by having DATABASECHANGELOG empty and run updateSQL against D1 and then getting proper insert statements for DATABASECHANGELOG.
If this is the case that something database specific is involved calculating MD5SUM, why is that then?
There should not be anything database specific in the md5sum. It is just ran on a normalized version of the changeset. The only reason I can think of off hand as to why it is failing is because you are using changelog parameters that have changed. What version of liquibase are you running? Is it just a few changesets, or all of them? Are you using different platforms to run liquibase on from one database to the next?
If you are getting checksum errors, you can simply update the md5sum column in databasechangelog to be null and it will update it with the correct md5sum on the next update.
The checksum is computed after the parameters are applied. The theory is that if you change the value passed in, the new changeset is different just like if you had replaced the hard-coded XML or sql.
You should be able to add an empty node to signify that the checksum should always be updated and should not fail if you have changeSets whos checksum is expected to change on a regular basis.
I have a couple of changesets that use changelog parameters, the values of which can change as a result of copying a database schema under a new name (you might wonder why, but it’s a long story), but I don’t want those changesets to be re-run on a given schema, and if the checksum should change, I just want Liquibase to ignore the changesets. After seeing this thread, I tried using in each changeset, but I still got checksum validation errors. Looking at the source code, ChangeSet.isCheckSumValid doesn’t appear to have any logic that gives special treatment to an empty validCheckSum element (either for 1.9.5, which I’m using, or the latest trunk code). Can you clarify whether there is actually any way of getting Liquibase to automatically ignore checksum changes and skip a given changeset (without manual intervention)?
Perhaps it would be worth having an ‘ignoreOnChange’ attribute (which defaults to false) for the changeSet element? I’m not averse to using a self-customised build of 1.9.5, but would be interested to know what the official solution might be in 2.0 (whether it’s validCheckSum or something else) so that I can eventually upgrade without needing to modify any of the ‘special’ changesets.
You are right. It must have been a feature I thought about but didn’t actually implement…
I commited a change to support any as an option. That will allow any checksum to be assumed to be correct. I thought it would be better than adding another attribute because it re-uses the existing functionality.
I tried using any, however it still calculates the checksum. Is there any way to not calculate the checksum? Reason being is that when using it takes a lot of time to calculate it and I’d rather skip it.
I’d second that. I have also such a element which takes 2 minutes to run, so the mandatory calculation of the checksum is very annoying in development, where every “mvn jetty:run” startup takes those two minutes.
One option woudl be to create a custom extension (liquibase.org/extensions) that subclasses LoadDataChange and overrides the generateCheckSum() method to always return a constant value.
