In my project, we used voltdb as database and we used liquibase for managing version and etc. We wrote changesets in one file and for voltdb and we used RunAlways.xml file which contains below steps
RunAlways.xml file ran after update of existing DB or for new DB also.
Let's say my change set for any procedure is
<changeSet dbms="voltdb" author="foo" id="foo-1" runAlways="true">
<sql>DROP PROCEDURE BAR</sql>
<rollback/>
</changeSet>
Now I changed the <sql>
statement and and changed statement is look like this
<sql>DROP PROCEDURE BAR IF EXISTS</sql>
After chnaging this I got
Unable to update database. liquibase.exception.ValidationFailedException: Validation Failed:
error.
As per one Liquibase blog if we reformat the <sql>
tage then it will affect the checksum.
So that I add <validCheckSum>ANY<validCheckSum>
tag before <sql>
tag. Now when ever RunAlways.xml will run it will not check for checkSum
and run always my chnageSet
without any error.
Now my question is, Instead of <validCheckSum>
tag rather I want to use <preconditions>
tag then how should I implement this? I found in on Liquibase blog that we can handle using <preconditions>
tag also.
Also there are other solutions as well like clearchecksums command and etc.
Prompt assistance will be highly appreciated.
There is a good argument that runAlways should ignore checksum errors, but currently it doesn't.
Adding the validCheckSum
probably makes the most sense so I'd suggest just sticking with that. It is the most explicit way of saying "This changeset may change from time to time and that is fine".
Adding runOnChange="true"
in addition to the runAlways="true"
would work too, but is a bit less obvious to people reading the changelog file what you are intending.
Clear-checksums is more for one-time/one-off "everything is changed" cases so not something to use on a regular basis like you seem to be looking for.
Preconditions are a way to add logic to dynamically determine if a changeset should run or not. For example, if your database didn't support the drop ... if exists
syntax, you would have to use one to see if the procedure exists before trying to drop it on a runAlways=true
changeset.
You may be able to replace all the runAlways=true
attributes with a combination of preconditions and/or runOnChange=true
settings which dynamically detect new versions of changesets and the current state of the database to determine what should run. Whether that is more complex or less complex than runAlways=true
is a judgement call for you to make.