I’m not quite sure if this is a bug, but at least it is a quite strange issue:
I have written an extension which ran without any problems on Liquibase 3.1.1. I switched to Liquibase 3.2.2 and made some changes to the extension class (added getters for every variable in the Change-class and adding @DatabaseChangeProperty annotations to them).
Now I get checksum errors on already ran changeSets, which is a bit unexpected to me as the changeSet itself did not change.
Is it intended that changes is the Change-Classes result in checksum-validation errors? What are the options to circumvent this?
Usually we try to keep the checksums consistent from release to release, but there were some large changes in how the parser works in 3.2 that caused some to change due to bugs.
Do you have an example of the the problem changeSets? Are they ones with your extension, or other ones?
You can tell how the checksums are computed with logLevel=DEBUG. If you run it in 3.1.1 and 3.2.2 you should be able to see what changed in the logic.
So it does look like the 3.2.2 version actually a bugfix that affects the calculation and probably not something we want to revert back to.
You have a couple options, you can override the generateCheckSum() method to not take the attributes into account anymore, but the better option is probably to use the tag in the problem changeSets. You can use any or use the new checksum you see in the validation error message.
Thank you for your response, the validChecksum tag seems to be a good alternative.
I’d like to discuss an issue that was mentioned in my last post here:
xxx: Computed checksum for changeAutoincrementValue:[
columnName=“xxx”
tableName=“xxx”
] as xxx
was the log entry for one examplary changeSet, the changeSet however requires 3 attributes, the “minValue” field was not considered in the checksum calculation (it is a BigInteger member in constrast to the “columnName” and “tableName” fields, which are strings). Why is this field not considered in the calculation?
the problem with the “minValue” Attribute was due to the fact that the setter for the variable in the class did not follow the Bean-contract. Everything seems fine now.
Thank you for your hint.
I’ve done the logging test you suggested.
3.1.1:
[30 Jul 2014 07:14:57,247] main DEBUG de.medav.dmf.server.base.MARServer.Container.LiquibaseService.liquibase - liquibase/db-changes.xml: liquibase/db-changes-4.4.xml::4.4.0-4c::tins: Computed checksum for changeAutoincrementValue:[] as 78fb688dce3de0e48421a8933c935ab3
3.2.2:
[30 Jul 2014 07:18:11,518] main DEBUG de.medav.dmf.server.base.MARServer.Container.LiquibaseService.liquibase - liquibase/db-changes.xml: liquibase/db-changes-4.4.xml::4.4.0-4c::tins: Computed checksum for changeAutoincrementValue:[
columnName=“Id_Language”
tableName=“mar_language”
] as b28775d91b0587713c6dbfd7b6a1ac9b
the correlating changeset:
set autoincrement value to the maximum of column + 1 or the passed minValue
<ext:changeAutoincrementValue tableName=“mar_language” columnName=“Id_Language” minValue=“1000000” />
Seeing the debug log, none XML-attributes of the changeset have been considered for the checksum with the 3.1.1 version of the extension, whereas the string attributes/values are included in the 3.2.2 versions (why are the BigInteger-defined “minValue” attribute and value not included in the checksum of 3.2.2?).
What are the options to fix this now? I won’t be able to get direct access to all the databases the changes have been run onto. I’m not sure if the “runOnChange” (or whatever the changeset-option is called) is a good idea either.
As stated in the original post, die extension used has been changed, I attach the 2 change-class versions (as a zip, as only one attachment is allowed).
