Prevent database modifcations for non-unique ID/Author/Filename?

I’m new to liquibase but excited I found it.

I think it’s exactly what we need…


One question as I get started,

shouldn’t the verifying a unique id/author combo be enforced before performing the database update?

(perhaps there is a way?)


For example,

Suppose I’m being lazy and copied a previous changelogFile.xml to start with my new set of changes…

However I only changed the schema, not the id/author name.


For example, using the sample from the quick-start, changing





When I run the migration the second time from the command line

It results in an error which should be expected…



liquibase.exception.DatabaseException: Error executing SQL INSERT INTO [DATABASECHANGELOG] ([AUTHOR], [COMMENTS], [DATEE
ATE(), ‘Create Table’, ‘EXECUTED’, ‘test.xml’, ‘1’, ‘2.0.1’, ‘3:34d8b912381655cc4a27585a08200457’, 3): Attempt to insert
 duplicate key row in object ‘DATABASECHANGELOG’ with unique index ‘DATABASECH_18240064981’



But shouldn’t it prevent the actual update and cancel/rollback if the changeset is not valid?


What I’ve discovered is that it will still perform the update modifying the database, adding the second table

but there is no record of it being tracked in DATABASECHANGELOG. 


That doesn’t seem correct…

My expectation would be that since the changeSet is invalid with an incorrect identifier, it should be rejected.




Yes, that isn’t right. You are testing with 2.0.1?


Yes. 2.0.1

I looked into it further today and found the root cause…


In the changeset.xml,

I had unknowingly included whitespace after the author name. (a tab actually)


However, the DB (sybase) strips trailing whitespace during insertion.


So, when validating for the second run,

the XML author containing the whitespace, is compared against the DB author where it was stripped,

Since they no longer match, it doesn’t trigger a validation exception.


This occurrs at line 96.


I’ll avoid trailing whitespace in the author name.

It seems like the best solution might be to always trim trailing whitespace on creation of ChangeSets/RanChangeSets, but I’m not sure how that affects other DB implementations.


But then again, Perhaps it should just reject the changeset outright if it parses an author name with a trailing space,

then it can prevent the whole thing from running in the first place…

(Since ‘fixing’ it later to remove the space will cause a change in the md5 hash, even though the changeset wasn’t logically modified)




Do you think this should be considered a bug and entered in JIRA?



Yeah, if you could add it, that would be great.



Added CORE-1030.