CODEWITHSUNDEEP
databaseliquibase
Manjunath
Manjunath

Reputation: 381

Liquibase throwing changeset validation errors when new changeset is added to existing Sql file

I am using Liquibase to manage DB migrations. I am facing validation errors against the changeset. The error is related to the checksum. I am using Sql format for the migrations i,e creating sql files. I added a changeset and it was successful and then I needed to modify a Table to add a new column so I just edited the Sql file where I had first changeset and added the second one jsut below and tried to re run. The migration failed by complaining about mismtached checksums for the first changeset. Is this correct way to add newer migrations or am I missing something. Any help would be greatly appreciated. Thanks

Below is the sample and similar Sql file I have. I added the second changeset later after the first one was successful. BTW, I am using dockerized format of Liquibase.

--liquibase formatted sql
--changeset author:1 endDelimiter://

CREATE DATABASE IF NOT EXISTS `cms` /*!40100 DEFAULT CHARACTER SET utf8 */;//
USE `cms`//
CREATE TABLE IF NOT EXISTS `clientProfile` (
  `clientId` int(11) NOT NULL AUTO_INCREMENT,
  `clientName` varchar(100) NOT NULL COMMENT 'Client Name')//

--liquibase formatted sql
--changeset author:2 endDelimiter:// 

USE `cms`//
ALTER TABLE `clientProfile` MODIFY COLUMN `clientName` varchar(255) NOT NULL COMMENT 'Client Name'//

Upvotes: 0

Views: 101

Answers (1)

Alexander Pletnev
Alexander Pletnev

Reputation: 3516

It is an expected behavior. Liquibase validates the checksums of the deployed changesets to ensure that the database schema corresponds to the desired state and to provide idempotency during deployment and rollbacks.

Is this correct way to add newer migrations or am I missing something.

No, it's not the correct way. In fact, never ever do that. The changesets should be atomic, immutable, reversible, and should only be modified in exceptional cases - for example, when it's impossible to fix an error by applying a new changeset, or when the risks of deploying an incorrect changeset are higher than the risks related to its modification. In case of such modification you have to add the previous changeset checksum to the changeset, and typically it's only acceptable when the changeset was not deployed anywhere outside your personal disposable development environment.

I'd recommend reading my answers to Liquibase fixing non-rerunnable changeset and Does Liquibase have a similar option to Flyway`s clean-on-validation-error questions, and, of course, check out the best practices (here and here) from Liquibase developers.

Upvotes: 0

Related Questions