We use Liquibase to manage our database deployments, and we recently had to restructure our project directories.
After the restructuring, we encountered Liquibase issues during the first liquibase update, due to the databasechangelog.filename column. The values stored in this column no longer match the actual changelog paths in the filesystem.
We cannot use the logicalFilePath attribute because the file path depends on the environment, and as far as I know, property substitution, does not work for this field.
I see three possible solutions, and I would like to know which one is recommended:
Solution 1
Run a liquibase changelog-sync right after the project restructuring. This would mark all changesets as already executed. However, this will result in two entries per changeset in the databasechangelog table (one with the old filename, one with the new one). Would rollbacks still work correctly in this scenario?
Solution 2
Directly update the databasechangelog.filename column to match the new paths across all databases. But I’m unsure whether this could cause side effects, especially with MD5 checksum validation or other internal mechanisms. Is this safe?
Solution 3
Manually set the logicalFilePath in each changelog file right before running liquibase update, adapting the path based on the environment. This might work, but we’re concerned about running Liquibase against changelog files that differ from the version in source control.