2

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

  • drop a procedure
  • create a jar file for all procedures
  • create a procedure in which changes were done
  • create partition if needed

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.

Deep Dalsania
  • 375
  • 3
  • 8
  • 22

1 Answers1

4

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.

Nathan Voxland
  • 15,453
  • 2
  • 48
  • 64
  • I'll stick to validCheckSum tag. You explained a all way to handle this error and also your last paragraph will be very useful for us. I tried to search and put preconditions as you mentioned but I couldn't able to because my precondition is my main logic so it's far better to use validCheckSum but we'll think about runOnChange=true attribute in precondition as you mentioned. Thank you – Deep Dalsania Sep 11 '21 at 03:52