LB 3.1.1
In the interest of DRY, Don’t Repeat Yourself, I tried referring to a changeSet from a previous release of our application for a rollback of a modification made this release. Upon running the next update, I got a SAXException from XMLChangeLogSAXHandler:336 because it couldn’t find the changeset I was referring to. This makes sense because we always feed only the changeSets from the most recent release into Liquibase when performing an update (We do have an install routine that feeds every known change into LB for empty schemas). We do this to prevent LB from having to parse files from several old releases that aren’t going to contain any new changes. We also do it as a safety measure to avoid surprises from maintenance branch merges. My strategy was that upon rollback, I would let LB see all the changes so that it could refer to any of them.
db-module/v1_3_2/db.changelog.xml <-- changeset modifying XYZ_VIEW is here
db-module/v1_3_3/db.changelog.xml <-- Another changeset modifying XYZ_VIEW, wanting to use the changeset above for
db-module/install.xml <-- Includes all previous releases in order and supporting files (constants, hack to set session current_schema, runAlways stuff)
db-module/update.xml <-- Includes only most recent release and supporting files
when we run liquibase update, we only show it the 1.3.3 file, and it fails. I understand wanting to parse the changelog in a manner that is independent of the task it’s going to be used for. Which is why XMLChangeLogSAXHandler is trying to make sure it’s well-formed.
Clearly I’m using this in an unintended manner. What do others do? Am I being too paranoid about not putting all of the previous releases in Liquibase’s sight when doing incremental updates?
