I am using liquibase scripts with Cordapp. And previously the first version databaseChangeLog file was having all table creations in one single change set and in a later point of time we have split it into different databaseChangeLog having each changeset.
Now the problem is some production testing environments have the data in it with the older script, but we want to use the new scripts.
The filename is part if the unique key on the databasechangelog table (ID/Author/Filename). So when you change the filename of a changeset that has already executed, that is now in-fact a new changeset according to Liquibase.
I normally recommend that my customers never manually update the databasechangelog table, but in this case I think it might be the best course of action for you. That way your new file structure is properly reflected in the databasechangelog table.
I would run an update-sql command on the new file structure, against one of your database where you have already executed the chagesets. This will show you what changesets are pending, and also the values for the filenames that you need to update.
MARK_RAN is treated the same as EXECUTED in the databasechangelog table.
The only thing you have to be careful with about preconditions is if the existing table structure in the database is different than the table structure in the changelogs. In that case you are “ignoring” an actual change that is needed.
We currently have a whole bunch of scripts that have been running fine for a few years.
A forthcoming upgrade to the server means that the syntax in that script is no longer valid on new deployments; if we change the syntax to align with the new version of the database server the scripts will run fine on new deployments, but break existing deployments as the checksum will have changed.
Are we going to have to manually change the checksum in existing deployments, or is there a better way around this?