Unexpected behaviour of preconditions with updateSQL

General Discussion
1

Hi

I’m using Liquibase 2.0-dev and have an issue with how preconditions are evaluated in updateSQL mode.
I’d expect that preconditions are evaluated and changesets get written to the SQL output file similar to when
they a changelog is applied to the database directly but that’s not the case. By default, preconditions are
ignored when in updateSQL mode.

I noticed that you can set an attribute ‘onSqlOutput’ on to one of [TEST|FAIL|IGNORE] whereas
IGNORE is the default. What is the difference between FAIL and TEST? I couldn’t see any.

How about changing the default behaviour to TEST (and set a default in the XSD as well) to be consistent
with the known update behaviour?

Cheers, Felix

2

The reason that preconditions do not execute in updateSQL mode is because preconditions are usually used to check the state assuming all changeSets up to that point were executed.  When running in updateSql mode, the actual database is in a different state during execution than you you would have at that point if you had been running in update mode.

Since there are cases that you know it is ok to still run a precondition even if no changesets have actually been executed, we added the onSqlOutput tag.  IGNORE just assumes that the precondition cannot be applied, but you should continue to “run” the changeLog.  TEST means to actually run the precondition.  FAIL mean to stop the execution of the changelog, alerting you that you cannot run in updateSql mode because a correct execution of the precondtion is required to continue.

Nathan

3

I cannot find any documentation for the onSqlOutput attribute. When will the documentation be produced?

Second, is the onSqlOutput feature stable enough to begin using in production?

Finally, if there is a way to set a global default for onSqlOutput=“TEST” that would be useful.

Our background: we’re currently evaluating Liquibase and one of the hang-ups is how to use Liquibase to generate db changes without actually running them. I expect preconditions to be used a lot. The updateSQL mode with heavy usage of onSqlOutput=“TEST” seems to be the most portable solution. We can run it internally, or a client can run it, and the output will be the full listing of SQL statements that implement preconditions and refactorings (far as I understand). We’ll be using 2.0 RC6 for evaluating Liquibase. But I would need the official docs to explain the onSqlOutput attribute so that I can be sure the functionality doesn’t simply disappear/break one day and leave us with a hundred files misusing it.

Sorry to revive an old thread but this is one of the few places where the onSqlOutput attribute is mentioned.

Thanks!

4

Sorry for the slow reply.

My plan is to document the liquibase APIs (including onSqlOutput) after 2.0 final is out.  It should be stable and ready for production use at this point, though.  The 2.0 release was primarily about cleaning up our internal APIs so they can be relied on by 3rd parties and what you are looking to do is what the onSqlOutput is for. 

Nathan

5

Great! Thanks for the hard work :slight_smile: