We had an issue whereby changesets that had been successfully run once (and marked as EXECUTED in the databasechangelog) would run the same changelog again later. We found that the changelogs that used "liquibase declarative syntax" were more prone to this than changelogs using .
We were running with full on DEBUG and noticed the checksum was happening against "the generated SQL", in particular around alter statements. This results in potentially different checksums between different versions of Liquibase, if the SQL generation changes.
What we still didn't understand is why the "runOnChange" 'logic' was invoked by default as we did not specify runAlways or runOnChange in our changesets. All we observed was that the job was rerunning already successful migrations.
We'd like to verify our assumptions and are curious about anything else that might have caused this
Hi Nathan,
I appreciate the response in the extreme.
The changeset was definitely re-executing though it’s useful to know that this causes the validation errors as well. One thing we noticed, after changing the logging level to DEBUG, is that it looks like checksums are being calculated on the SQL and not the declarative statements, in particular alter table type changes, though, admittedly this is somewhat conjecture. We also had a couple versions of Liquibase reporting in. In one case we have 3.2.2, in another 3.1.1 and, in my system, ${project.version}. We’ve since rectified the version issues, on the assumption that any SQL generation changes you make in Liquibase will result in different checksums for the same changelog.
That said, it’s just not clear why the changelog runs again in some cases when EXECUTED is set, and the ID, AUTHOR and FILE have not changed. One thing we were wondering about is that our ID’s are the name of the file, so have the .xml ending and wondering if that’s causing problems with a regular expression or something.
Thank you very much for any help you might have with this additional information.
Sincerely,
Tim
Hi Nathan,
Below is a 'sanitized' changelog that was re-running every time. The databasechangelog showed this as "EXECUTED" and the filename/author/id had not changed. It just fails on subsequent runs with duplicate constraint violations.
Thanks very, very much for any light you can shed…
<databaseChangeLog xmlns=“http://www.liquibase.org/xml/ns/dbchangelog”
xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”
xmlns:ext=“http://www.liquibase.org.xml/ns/dbchangelog-ext”
xsi:schemaLocation=“http://www.liquibase.org/xml/ns/dbchangelog http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-3.1.xsd”>
It is strange you are seeing that. RunOnChange defaults to false so if the checksums change you should get validationErrors, not re-execution. Also, the checksum is normally done against a standardizes version of the XML, not the generated SQL.
One thing that can cause people to see re-execution of changeSets is if the changelog file path changes. The path is part of the changeset identifier, so if you move the file or refer to it differently, it will count the changeSet as different. You should be able to select from the databasechangelog table to see the path of the changeSets previously executed and compare them to what Liquibase thinks it is now.
If it is not a problem with the path, could you post an example of the debug log and/or the changelog?
Nathan
Are the changes based on the SQL or changes? Or are they and other changes?
The IDs matching the filenames shouldn’t matter. They are just treated as strings in liquibase.
Nathan
