runAlways

Uses

Normally, when you deploy a changeset to your database with the update command, Liquibase adds a row to the DATABASECHANGELOG table to keep track of it. In every later deployment, Liquibase checks the DATABASECHANGELOG table, sees that the changeset has already been deployed, and skips it.

However, if you need a changeset to repeat an action on every deployment, you can set runAlways to true for that changeset. Possible workflows include:

• Using update to specify the current timestamp in a table in your database

• Using tagDatabase to tag the current state of your database

• Using sql or sqlFile to run a script that dynamically updates object permissions

In these examples, you wouldn't necessarily change the changesets themselves in a deployment. However, you would want these changesets to run again because they behave based on how other parts of your database will have changed.

Note: Setting runAlways to true on changesets that don't need to be run more than once may slow down your database updates.

If you want to run a changeset on deployment only if it was updated since the last deployment, you should use runOnChange instead of runAlways.

Modifying a runAlways changeset

Liquibase will throw a checksum error if you modify the contents of an existing runAlways changeset. If you need to make a change to an existing runAlways changeset, you must either:

• Remove the runAlways attribute from the existing changeset and create a new changeset marked with runAlways.

• Or use both a runAlways and runOnChange attribute in your existing changeset.

Syntax

Note: All changelog attributes use the camelCase format.

The default value for runAlways is false. Set runAlways to true on changesets that you want to execute on every migration.