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 <rollback>
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?