Precondition issues

General Discussion
1

Hi all. First I want to say thank you for putting out Liquibase it’s been a huge help.

The issue that I’m having revolves around the preconditions tag. The problem is that for my use there are existing databases that will start to use Liquibase for managing the application of SQL changes as well as databases that will be newly installed using Liquibase from the start. They all use the same schema and table definitions.

I have my install.xml defined like the following:

  1. <?xml version="1.0" encoding="UTF-8"?>
     

         
            
                
            
        


       
       
       
       
       


       


       
       
       
       
       
       

       


       
       


       
       




The idea is to have the precondition check to see if a table named control exists and if it does to assume that the database exists and is at the version cutoff to start using Liquibase change logs. The problem is that the precondition tag when used with databaseChangeLog does not support anything besides WARN or HALT for the onFail attribute. Currently I am chaining the install and the update batch calls so that if the install fails the update liquibase call still runs. If I use HALT it messes things up with an error message and stack trace. Does anyone have any suggestions besides putting in preconditions in every changeset to make use of onFail=“MARK_RAN”?

Thanks in advance for your help.

2

We don’t support MARK_RAN on the changelog level, because there is no changeset to mark ran at that level.  Unfortunately, the most straightforward way is to add the precondition to each changeset.  


If you are using 2.0, you can create a custom precondition to move your check logic to java and be consistant between changesets.  That way your XML can be:


     ext:isNewDatabase/

 …


and it would be up to your isNewDatabase extension to know how to look it up if it was a new install.  Since every changeSet would be modified the same way, you could write an XML parser/writer that woudl take the old xml and add in the new tags if there are a lot of them.


Another option (with 2.0) is to write a custom changelog parser (extending the base XML parser) which looks at the state of your database, then supresses old changeSets if they are in the old changelogs and should not be ran.


Nathan