[Liquibase 2.0 rc7] - ChangeSet preconditions with dbms check are not validated

Liquibase Development
1

I was trying the current trunk version of liquibase with an old change log we have based on the 1.9 version and ran into a problem using change set preconditions. In the previous version I could define a changeset like this:

Running this changeset on MS SQL with 2.0rc7-snapshot results in the error message

    Validation Failed:     1 changes have validation failures          createSequence is not supported on mssql, path/changelog::1::testAuthor::(Checksum: 2:17699b538d82105bd31ebd971af86136)

Running the same on Liquibase 1.9.5 just marks the change set as run an continues. I did some checking on this because it might be one of the undocumented changes for Liquibase 2 (it is not on the Upgrade Guide). Attached is a unit test checking the precondition, the problem might be in the DatabaseChangeLog.validate() method, this one already fails, but checking the precondition itself just validates.

I am not completly sure what the task of validate is. Does it need to check if all change set descriptions (addColumn, addTable, createPrimaryKey) can be executed on the datatabase or must it also validate the preconditions, for preconditions that HALT the operation?

Can you please verify the test case and the problem described?

Thanks

Regards,
Chris

	  
	  
2

It should skip the creation like it did on 1.9.  I included your test and fixed the code. 

Nathan

3

Okay, thanks. I will test this for my 1.9.5 change logs.

I was looking why it failed in the DatabaseChangeLog.validate method. The comment on the method says Checks changelogs for bad MD5Sums and preconditions before attempting a migration, but it seems it is not checking preconditions and is checking if changesets can be executed on the target database.

I noticed per SqlStatement it is now possible to set skipOnUnsupported. Does this only affect the validation of the change log or does it also skip a change when it is executing the change log?

Chris

4

The comment was out of date, I will remove it.  The validate method should be doing a general check of if the changelog can be ran, which would include failing preconditions, checksums, and unsupported changes for the given database. 

The skipOnUnsupported is used by both the validation and the execution.  It was the method I added to support this use case.

Nathan

5

How does the skipOnUnsupported relate the the ChangeSet.onValidationFail option? I guess when i would put onValidationFail on a createSequence statement for MSSQL the skipOnUnsupported overrules it? I don’t really get onValidationFail, does this new skipOnUnsupported make it obsolete (knowing that the onValidationFail can be set by the user). Personally I would say if we know the validation is not correct it must be fixed.

Chris

6

The difference is if the statement thinks it should be skipped if not supported, or if we want to leave it up to the changeset writer.  I think the normal use (and as a best case, only use), would be to leave it up to the changeSet writer, but there are a few places where we have traditionally had changes that “knew” enough to work with different database types (such as creating and dropping sequences). 

I was slow responding because I was going back and forth on whether I should take the skipOnUnsupported back out with 2.0 and force people to change their scripts to explicitly say “don’t fail validation for these changes”.  I think it’s best to leave that functionality, and there may be use for custom changes to use it as well, although I am not going to add it to any other built-in change types going forward.

So skipOnUnsupported forces them to be skipped no matter what you have for onValidationFail.  You only need to set onValidationFail for change types that have skipOnUnsupported=false (which should be most)

Nathan