Applies to:
- Liquibase Pro
- Liquibase Open Source (Community)
Conditions:
- Liquibase v4.23.0 or greater
Issue Summary:
When using a Liquibase command that causes a validation to occur, such as validate
, status
, update
, etc., a validation error is thrown that there are duplicate identifiers.
Error Message:
From v4.29.1:
ERROR: Exception Details
ERROR: Exception Primary Class: ValidationFailedException
ERROR: Exception Primary Reason: Validation Failed:
1 changesets had duplicate identifiers
<path>/<file_name>::<ID>::<author>
Root Cause:
In Liquibase v4.23.0, another validation check was added to determine if there are any changesets in the project with a duplicate identifier. The identifier is the file path, file name, ID, and author. This check ensures that all changesets have a unique identifier.
Example:
If there is a changelog file, createTable.sql, that contains the following:
-- liquibase formatted sql
-- changeset liquibase_support:1
create table employee ( emp_id serial primary key );
-- rollback not required
-- changeset liquibase_support:1
create table employee2 ( emp_id serial primary key );
-- rollback not required
Then running the validate
or update
command would cause the validation error below:
ERROR: Exception Details
ERROR: Exception Primary Class: ValidationFailedException
ERROR: Exception Primary Reason: Validation Failed:
1 changesets had duplicate identifiers
createTable.sql::1::liquibase_support
Resolution:
The error indicates which changeset Liquibase has found to have a duplicate identifier. In the example above, the error shows createTable.sql::1::liquibase_support
. This means that there is another changeset in that file that contains the same author and ID.
Change duplicate identifier
The duplicate identifier can have either the author or ID changed, which resolves this error.
Duplicate identifiers after upgrading
After upgrading, it is critical to find the duplicate identifiers and modify them. 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.
If needing to do an emergency deployment, a property that was introduced in v4.25.1, allow-duplicated-changeset-identifiers, can be used to have Liquibase ignore that there are duplicate identifiers while this attribute is set.
After upgrading, the best solution is to find all of the duplicate identifiers and do one of the following:
- Change the identifier
- This option requires a changelog-sync to be run. Otherwise, Liquibase will attempt to run the changeset as a new changeset as it is not in the DATABASECHANGELOG table.
- If any of the changesets that have duplicate identifiers are no longer needed or have already been deployed to all environments, the ignore attribute can be added to the changeset.
Comments
0 comments
Article is closed for comments.