duplicate identifiers

General Discussion
1

Hi gurus,

I have been using liquibase for longer than a year now, and have a pretty large project organized into several databasechangelog files, which are later combined into a larger one by means of the include directive.

I have stumbled upon a problem with duplicate identifiers when I add a new databasechangelog to my master file.

I know where the error comes from, I have two different files included which happen to have changsets with the same ids. However, that was done on purpose. It shouldn’t be a problem so long as liquibase has a proper databasechangelog db table. 

My question is, is there a configuration setting, or workaround to force liquibase to skip duplicate identifier validation?

I know about this bug https://liquibase.jira.com/browse/CORE-1332 , but it is unrelated

Mine looks more like what somebody described here long ago.  https://www.mail-archive.com/liquibase-user@lists.sourceforge.net/msg01282.html

Any comments, or pointers will be highly appreciated.

2

Thanks for your answer Steve. I am not quite sure if it was a good idea, but in order to allow “rebasing” in the future, we did something like this.

         base version x ( typical liquibase usage ). Base version x is always the same

               x  —>   x + 1 —> x + 2

         base version y ( “rebasing” pattern). Base version y can be changed, and start creating upgrade scripts from a new base version at any time.

Scenario A)

               y  —>   y + 1 —> y + 2 

(our db scripts went out of hand and are too long to run, or just inefficient,  we decide to clean y + 2 scripts a little bit, and start from scratch again, but  also allowing to upgrade all the way from y to y + 4. This results in two different paths. One in which you started from y or y + 1 all the way to y +2, and a different one in which you started from y + 2)

Scenario B)

            y + 2  —> y + 3 —> y + 4 

         

In order to support this kind of scenarios, which we don’t do often, we have y + 2 changesets which share the id, author and have logicalFilenamePath set to a predefined value, so they look the same. No matter which path you took, liquibase will know if the changeset for y + 2 has been run or not by lookin at his databasechangelog.

The down side is that you can’t have the changesets from both scenario A and B combined in the same top level changelog, since y +2 changesets will cause a duplicate identifiers validation error.

There is an easy fix for this, just removing y + 2 upgrade changesets from the build, but at the cost of losing one shot upgrades from release y, or y + 1 all the way to y + 4.

I hope my explanation makes sense, it is somewhat difficult to explain without graphics.

Many thanks for your answer again

         

3

There is not a configuration setting or workaround that I know of. 

I’m curious though why you would want this behavior. If you have two things with duplicate identifiers, how should the system decide which one to use? Are you referring to just the changeset id, or do you have things that have all three parts duplicated? (the changesetid, the author, and the path)

Steve Donie
Principal Software Engineer
Datical, Inc. http://www.datical.com/