ChangeSet uniqueness causing issues with branched releases (overlapped changes not allowed in different files)

What you are trying to do does go against some of the base assumptions liquibase uses: namely that each changeset is unique and not copied across multiple places.


One option would be to add a to the changesets checking whether it has ran or not. For example, using in a changeSet that creates a table. If you use onFail=MARK_RAN, then if the table exists the changeSet will just be marked as ran.


With the extension framework (liquibase.org/extension) there is the option of creating extensions to the changelog parsing classes which can use custom logic to strip out duplicate changeSets before the DatabaseChangeLog object is passed to the validator.


A final option would be to change your changelog naming/organization strategy and have a “changelog-per-feature” approach and each version/client would chose the feature changelogs to include. How well that would work depends on your code and project structure.


Any of those options help?


Nathan



Thanks, just what I was looking for!

I guess I spoke a bit too fast.  I am not necessarily moving a change set from one change log to another, but rather copying it… in my example above, the 5.0.1 and 5.0.2 change logs have some of the same change sets and some that are unique to each release.  So when upgrading to 5.1, I wanted to apply both those change logs.  Using the logicalFilePath worked, but instead ran into a different liquibase validation issue telling me there are duplicate identifiers.  This seems to be detailed in: http://liquibase.jira.com/browse/CORE-449.

Hello,

I am looking into Liquibase for our product and am very happy with it so far, there is just one limitation that could be an issue with our product.  We have branched releases of our product all the time as we have few customers, but large customers, and they drive our development paths.  For example, we had a main release of 5.0 that went to all customers, we then had a release of 5.0.1 then went to customer A and 5.0.2 which went to customer B.  Each release added different features with a little bit of overlap.  Then in 5.1 the features from 5.0.1 and 5.0.2 were brought together for all customers.


So the issue with this is, following the Liquibase Best Practices (http://www.liquibase.org/bestpractices), we have 4 liquibase change log files:


db.changelog-master.xml

db.changelog-5.0.1.xml

db.changelog-5.0.2.xml

db.changelog-5.1.xml


Now the 5.0.1 and 5.0.2 files have some changes that are the same, lets say they both add table NEW_TABLE, but other changes that are different.  I was hoping that if the changes which are the same used the same author and changeset id, that when all the files are loaded it would recognize those changes as the same and not attempt to re-run them.  Unfortunately because they have different file names, it still tries to run the same changes from both files, resulting in errors.  I understand this is most likely not a common development path for most users, but is there a better way to handle this other than storing all the changes in separate files?  It would be nice to have the option to make the unique key only on author and ID.

Both a changeSet element from one changelog file to another, you don’t get into nasty re-identification issues.

Hope that helps you out.  That should give you full control over your environment.

Best,
Laird


http://about.me/lairdnelson