allow-duplicated-changeset-identifiers

--allow-duplicated-changeset-identifiers is a global Boolean parameter. You can use it to specify whether Liquibase lets you deploy multiple changesets with the same filepath, author, and ID. It is available in Liquibase 4.25.1 and later. The default value is false.

Uses

By default, Liquibase requires every changeset to have a unique identifier, which is the filepath of the changelog combined with the author and ID of the changeset. This ensures that each of your changes are clear and distinct.

When you deploy a changeset, Liquibase creates a row for that changeset in your DATABASECHANGELOG table. If any changesets contain duplicate identifiers (which would create duplicate rows in the DBCL table), Liquibase halts the deployment:

Unexpected error running Liquibase: Validation Failed:
     1 changesets had duplicate identifiers
          example-changelog.xml::duplication-test::liquibase-user

However, your changelog may contain changesets with duplicated identifiers. Developers may have manually added these changesets out of the normal Liquibase process. If your changelog is very large, it may be unfeasible to remove them manually. To ignore the duplicates, set --allow-duplicated-changeset-identifiers to true.

This way, Liquibase only creates a row in your DATABASECHANGELOG table for the first changeset with a duplicated identifier. For every following changeset with that duplicated identifier, Liquibase does not create a new row. This means your duplicated changesets are not deployed to your database, but Liquibase will not treat the duplicates like errors, so it will not halt during the deployment.

Tip: Reusing identifiers can be confusing to developers and may lead to unexpected rollback behavior. It is a best practice to use distinct identifiers for every changeset in Liquibase.

Rolling back changes with the same identifier

If you have two changesets with the same identifier, you can use the rollback, rollback-count, rollback-one-update, and rollback-to-date commands normally. For these commands, there is no difference in rolling back a changeset with a duplicated identifier or a unique identifier.

However, the rollback-one-changeset command only targets the first changeset because it is the only one that appears in the DATABASECHANGELOG table. When you run rollback-one-changeset and specify your duplicated identifier, Liquibase rolls back only the first changeset. To avoid checksum errors, you must also specify --allow-duplicated-changeset-identifiers=true when running this rollback command. For example:

liquibase
    --allow-duplicated-changeset-identifiers=true
  rollback-one-changeset
    --changeset-path=example-changelog.xml
    --changeset-author=liquibase-user
    --changeset-id=duplication-test
    --force

Syntax

You can set this parameter in the following ways:

Option Syntax
Liquibase properties file 
liquibase.allowDuplicatedChangesetIdentifiers: <true|false>
Global flow file argument (example) 
stages:
  Default:
    actions:
      - type: liquibase
        command: update
        globalArgs: { allow-duplicated-changeset-identifiers: "<true|false>" }
Global CLI parameter 
liquibase
 --allow-duplicated-changeset-identifiers=<true|false> update
 --changelog-file=example-changelog.xml

JVM system property (JAVA_OPTS Environment Variable)

 
JAVA_OPTS=-Dliquibase.allowDuplicatedChangesetIdentifiers=<true|false>
Liquibase Environment Variables 
LIQUIBASE_ALLOW_DUPLICATED_CHANGESET_IDENTIFIERS=<true|false>

For more information, see Working with Command Parameters.

Related links