The ChangeSet filename shouldn't be part of the changetset uniqueness criteria

At lest remove path form the changeset name in DB !

I also ran into problem of manually running changelogSync from the directory containing the changeset file (cd src/main/liquibase)and that created changelogfile field value to DB as "db.changelog.xml".
Then when I ran the maven build which will retrieve the SAME changelog file from different path "src/main/resources/liquibase/db.changelog.xml" and liquibase tried to apply all the changesets again.

>cd src/main/resources/liquibase
>java -jar liquibase.jar changelogSync
Liquibase 'changelogSync' Successful
>java -jar liquibase.jar status
...is up to date
>cd ../../..

•  

  •  

    • now running liquibase via maven that takes and overrides driver jar and changeset paths (can be simulated by editing values in liquibase.properties file to have extra path names **

>java -jar src/main/resources/liquibase/liquibase.jar --defaultsFile=src/main/resources/liquibase/liquibase.properties status
76 change sets have not been applied to ...

Liquibase treats same changeset file as completely different file when the same changeset file it is ran from different relative path.

Yes, there could definitely be a separate issue on options to help keep filenames from changing.

Before opening a new issue, I'd like to comment here and point out that there may be a valid bug here. The problem isn't necessarily with filename uniqueness but with path uniqueness. I have discovered that if the path to the same file changes from one pass to another, liquibase doesn't recognize the changeset has been run and tries to run them again.

For instance, let's say that you have one change set but instead of running it in /tmp/foo, you run the change sets in /opt/foo

Because the file path is different, liquibase will attempt to run the changeset again even if the changeset id is already in the database.

Merely moving the change sets to the directory where they were originally run against that same database will prevent errors. This seems like a pretty serious bug.

Yes, there are times that the filename can be done without, but there is also functionality that is much easier to support and/or only possible with having the filename as a part of the ID.

If you would rather not have the filename included, the easiest work-around is to specify the logicalFileName attributein the databaseChangeLog tag to a constant value across all of your changelogs. This is the filename that will be used no matter what the actual filename is. You could also override a few points using the extensibility framework (http://liquibase.org/extensions) to always use a constant filename. This would be an extension worth publishing for others for whom the filename gets in the way.

I think you can also specify a logicalFileName per changeSet if you do need to move changesets between changelogs.

At this point it is an important feature for liquibase, and cannot be removed although it can be worked around if you need or like.

Hi Nathan,

Thanks for your answer.

What is a changeset for a database ? Most of the time it'll be a database structure alteration, for instance, add a column to table B. Whether the changeset is defined in/applied from file changesForTableB.xml or file yyyyMMdd.xml, it is still the same changeset from the database point of view, and liquibase should consider it as such in my opinion.

I understand your point, as using the filename, will reduce the risk of conflicts between developers where the same id/author are used in different files. However, this problem can easily be circumvented using naming conventions or else (we usually use the id of the issue it relates to in the version tracker). Moreover, if the same id/author was used in two different files, and if liquibase was not considering the filename for uniquess, the tool would still complain and fail before doing anything (duplicate changeset detected), and the problem could still be easily addressed.

Using the filename for changesets uniqueness is very contraining as you cannot move changesets between files without manually synchronizing the changelogs.

Thanks,

Nic