Does Liquibase Support Dry Run

Does Liquibase support dry run?

You can try "updateSQL" mode, it will connect db (check you access rights), acquire db lock, generate / print SQL sentences to be applied (based on db state and you current liquibase change sets) also it will print chageset id's missing in current state of db and release db lock.

Is there a way to actually execute a DDL update with liquibase-maven-plugin?

Incorrect. The update command will actually apply the changes to the database. The updateSQL is there to generate the SQL that would be applied, for use when you can't run Liquibase in a certain environment (i.e. your DBAs won't let you run Liquibase in production) or to preview the SQL before applying it.

There are some demos showing the basic workflow in the Liquibase YouTube channel.

Can you control Liquibase updateSQL output by major release?

There are several ways to run a portion of your changelog.

If you break up your changelog files using versions (changelog-1.0.xml, changelog-1.1.xml, changelog-2.0.xml) and then have a master changelog.xml that <include>'s them, then the easiest solution for you may be to just run updateSql passing in the changelog version you want. If you want to generate sql for the entire database, run "liquibase --changelogFile=master.changelog.xml updateSql". If you want to generate sql for just version 2.1, run "liquibase --changeLogFile=changelog-2.1.xml updateSql"

@Jens answer works well and is what I often suggest. It has the advantage compared to the above option of catching new changeSets that were introduced into old changelog versions through a merged in patch release, for example.

Beyond that, you could use context or preconditions to dynamically control what is ran. Depending on your setup there may be ways to get those to work well for you.

Finally, there is always the extension system where you can write custom logic around how changelogs are parsed and executed to pull out older version changeSets based on file name or some other mechanism that works for you.

Does Liquibase Rollback automatically when Update command fails?

Changeset 1 will still be applied to the database and the DATABASECHANGELOG table will reflect that the changeset was applied. If you then fix whatever problem caused the update to fail and re-run your update, it will see that changeset 1 has already been deployed and only deploy changesets 2 and 3.

SQL Server query dry run

Use an SQL transaction to make your changes then back them out.

Before you execute your script:

BEGIN TRANSACTION;

After you execute your script and have done your checking:

ROLLBACK TRANSACTION;

Every change in your script will then be undone.

Note: Make sure you don't have a COMMIT in your script!

Liquibase commits changeset partially

It is not Liquibase that is committing a changeset partially.
I have worked with many databases and a basic concept for all the databases I used, is that a transaction combines data modifications (DML) only.

DDL is never part of a transaction. It is always executed immediately and an open transaction is automatically committed before it is executed.
The reason for that is that the rollback command of a database can handle data modifications only. It can't handle DDL. And if a rollback is not possible anymore then keeping the transaction open becomes useless.

So, Liquibase does create a transaction and commits all changes at the end as the doucmentation states. But that works only if the changeset contains DML only, no DDL.

And because of that DDL and DML should never be mixed in one changeset and every DDL statement should be in a separate changeset. Otherwise there is no way that Liquibase can prevent a changeset from partially succeeding and causing trouble when trying to rollback.

Better understanding how Liquibase execute change sets

I can answer a few questions, perhaps not all though.

1. c. - Liquibase creates 2 new tables in the database when you do the first update. The main table is DATABASECHANGELOG, and that is used to keep track of what change sets have been applied to the database. Liquibase uses a couple of ways to identify each changeset - the id, author, and path are used as a composite key. Liquibase also generates a checksum of each changeset that is used to tell whether the changeset has been altered after being applied to the database.

2. and 3. Because the change set id and author are used as part of the primary key, if you deploy, then change either one of those, you may run into unexpected behavior on subsequent deploys. I think that the id and author are also part of the checksum calculation, so that might affect things also. I would recommend that you do not change those after deploying.

3. Rollback uses the same mechanism to know what change sets to roll back. When you roll back you have to specify in some way what changes to undo - see this page for more info: http://www.liquibase.org/documentation/rollback.html

The rollback identification mechanisms are by tag (which means you have to apply tags when you deploy), by date (Liquibase keeps track of when each changeset was deployed), or by number (which implicitly uses the date/time of when each changeset was deployed).

---

Related Topics