Two projects using liquibase, how to handle conflicts in changelogs?

Question

We have two projects. Project A is a basic project that provides basic functionality which we will be releasing internally for others to build off of, project B is our specific project which uses's A's basic functionality.

Both project A and B use the same database and have their own liquibase changesets.

I want to modify one of project A's base classes, call it entity. We had an entityId (not the same as the DB primary key) field and later realized it was not needed because other fields serve to uniquely identify the class. We want to remove entityId from the entity class, and the database that backs it. I updated project A's liquibase file to remove entityId column.

However, at some point awhile ago in project B someone decided they wanted to rename some entities they had created. They wrote into project B's liquibase changeset to rename entity with entityId x from "foo" to "bar". This is part of an old change multuple revisions ago.

The problem is that project A's liquibase changeset runs before project B's. Therefore A removes the entityId from the entity table before B can run and rename specific entity "foo" to "bar" based off of it's entityId, I get an exception saying entityId doesn't exist when we try to run B's changeset.

I would be happy to change the old changeset to do the rename based off of the name, ie rename any entity with name "foo" to "bar". However, I can't go back and modify the old changelogs because there is apparently a checksum saved in the database, if we change the file we will get a checksum exception basically complaining that the old file was changed.

So my question is, how is one suppose to handle this? Can I remove entityId from project A without breaking project B's liquibase?

Furthermore, is this approach right? Have we done something wrong by having one project create the table for an entity and another project populate it? can two different projects have separate liquibase changesets for the same database, or does this always lead to problems?

Answer 1

I'm not quite sure what sense you're using "project" here, but I'm assuming it means something like what I would call "team".

Either way, it looks like the answer to your last question is yes, you have done something wrong. And I guess that "something" is that your two projects are not sharing he same codebase.

If they were sharing the codebase, then the person applying the second change would have been aware that the first change existed, if only because they'd have seen it when they updated their code from the version-control repository.

So for the future the answer is that your projects need to be sharing common code, including Liquibase changesets.

Recovering

But that doesn't help you recover from where you are now. You're right to acknowledge that it's unwise to change a changeset that has been run. There are ways around that, though; for example you can delete the associated row from DATABASECHANGELOG.

That might not be wise either, though. It all depends on the fine details.

In fact the easiest solution would probably be to ensure that Project A's changeset runs after Project B's. That way the renames will happen, and then the column will get dropped.

Though you also have to consider that maybe your entityId column really is needed after all, since Project B seem to be making use of it.

Alternatively

If for some reason you can't do that, then you ought to be able to work around the situation with judicious use of the <preConditions> element. That will allow you to execute particular changesets or not depending on the state of the schema.