Checksum calc is different
Description
Environment
Linux
Attachments
Activity
Nathan Voxland October 31, 2014 at 6:35 PM
Your example with the CSV is actually due to an unavoidable checksum change from fixing a bug. In 3.1.x the checksum in loadData did not take into account the table name but was fixed in 3.2 to include it. It should be included or changes to the target table will not be caught but that means the checksum changed, unfortunately.
Your best approach would be to use the <validCheckSum> tag in the changeSet to mark 7:56314577e3ccd500b5d49d7c4f0a2660 as a valid checksum.
Benoît Courtine July 29, 2014 at 11:58 AM
After upgrading to 3.2.2, I confirm that the problem is still present:
With 3.1.X, the same changeset pass without checksum error. In databasechangelog, the checksum for this changeset is "7:71c6cc1b70de65ea92a1f48e1c9a92b4" (applied with Liquibase version 3.0.0-SNP).
Benoît Courtine July 24, 2014 at 6:27 AM
CSV file corresponding to the changeset.
Benoît Courtine July 24, 2014 at 6:27 AM
I will test the new version, but my changeset dostn't use "defaultValueNumeric" or "valueNumeric".
Here is the changeset :
I attach the pays.csv file to the ticket.
Nathan Voxland July 23, 2014 at 8:59 PM
I believe this was fixed in 3.2.2 for changeSets that use defaultValueNumeric or valueNumeric.
In a project, I have changeset files that are applied by maven-liquibase-plugin.
Some of theses changesets have type "loadData", to load tables from CSV files.
With 3.1.1 version, theses changesets are OK.
After upgrading the maven plugin from 3.1.1 to 3.2.1, the build fails, because the checksums of theses "loadData" changesets are different.
I don't know if this problem only affects the Maven plugin or also "liquibase-core".