I have a set of changeLogs that apply changes to an existing DB. The existing DB is tagged with version X. My master.xml script for the update changeLogs has a precondition to check that we are running against version X. This seems to work OK. At the end of the update, the database is tagged with version Y (using a new dummy changeLog entry and a tag).
I have been using the doc examples for creating a dummy changeLog to tag the previous version, i.e.
I currently use the following structure to apply updates for build 2.0.0 over build 1.0.0:
SELECT ISNULL(MAX(id),0) FROM databasechangelog
<include file="update/2.0.0/111.xml"/> <include file="update/2.0.0/116.xml"/> <include file="update/2.0.0/123.xml"/> <changeSet author="MajorVersion" id="200"/-->
In addition to this, I tag these update changes with tag 200.
Now - if I want to rollback these changeLogs - this isn’t going to work using the same master.xml as the preconditions will now fail.
How would you recommend I structure the files so that the rollback functionality works on a DB tagged with a newer version? A rollback is only likely to be run after a full update has completed. I could create a rollback.xml in each major version folder which includes the same files in the master.xml, but has an updated precondition. Is there best-practice in this area?
What’s the value of using a dummy changeLog (setting MajorVersion = 100) rather than using just LiquiBase’s own tag functionality?