I have a changelog that worked just fine, now for no reason (at least one I can find) all the changesets have changed checksum. The checksum I describe below went from 2:079b940a8b8a1c413e80abe52447f4c4 to 3:2bf92b9e42fc2473a299f83497eadf2f and all the checksum from the other 91 changesets used to start with 2: and now start with 3:
91 change sets check sum
base_dbchanges.xml::base_1::ricardo is now: 3:2bf92b9e42fc2473a299f83497eadf2f
Thanks totalylou…, it helps alot. I’m just wondering what could cause this change in the checksum, before just reseting it. My changeSets do not contain elements, no liquibase updates in between, and they look alike between branches.
We ran a git-merge-conflict-resolution in between thou, so I’m trying to figure out what we could go wrong.
Im no expert, just a user But if I had to guess, my bet would be on file encoding. me and my associate use different OS (Mac and Linux) and I believe the file encoding (maybe the line break) can be an issue that can cause this problem.
Anyway, I solved my problem with ValidChecksum and moved on
There is sometimes a checksum change when upgrading liquibase because of changes in the algorithm, otherwise we do try to normalize as best as possible. If you are using changelog parameters the value of them are taken into account, so that may make a difference if the values change.
If you run liquibase with --logLevel=debug it will output the strings that are checksum’ed which may help you see what may have changed.
I recently started to use liquibase 3.0.2, and I was very surprised to notice that running liquibase status against database managed so far with liquibase 2.0.x lead to silently convert all the changeset checksums.
Notes (please tell me if you prefer that I shift this stuff to a separate forum thread):
In my experience, running again "liquibase status" with 2.0.x (tested with 2.0.3 and 2.0.5) did not recompute the checksums, but generate checksum mismatch alarm. I'll give a second try (maybe I should put/remove an option).
I also noticed that some DATABASECHANGELOG.checksum fields are empty after the upgrade... and it looks not very good to me. What do you think? (I have no access now to the data, but I can provide more information in the next days)
Yes, the checksum algorithm changed from 2.x to 3.x and so Liquibase updates them. I had added a note on http://www.liquibase.org/v3_upgrade.html about how the runOnChange logic was affected by the changing checksum, but I’ll add some more checksum-specific explanation.
If you downgrade to 2.x, it should “fix” the checksums back, it just can’t tell if there are changes due to the incompatible checksum versions.
I think it makes sense that status gives checksum mismatch alarms. I don’t think it should just fix them on a status, but it should also handle it better. I created https://liquibase.jira.com/browse/CORE-1435 to track that feature.
The checksum fields should not end up empty. They get cleared out but then should get repopulated. Can you let me know if you are seeing them end up null and what commands you ran to get them like that?