Change sets and topological sorting

I’m wondering to what degree–if any–LiquiBase is aware of items in a change set that depend on each other.

My hunch is that LiquiBase leaves this up to the developer.

Here’s what I’m getting at.  Suppose I have a changeset, id 1, author me.  And suppose in that change set I create a table, and add some columns.  Suppose further that one of those columns is a foreign key to another table that…oops!  I should mark this change set as id 2, and back up and put in change set id 1 to create that target table.

Are there any shortcut refactorings or other features that make this kind of ordering and dependency management easier?


Liquibase doesn’t know how the changesets affect or depend on one another, it’s up to the developer to track that.  It simply starts at the top and goes down in order. 

The changelog is a file that you should think of as append-only.  In your example, you would want to create changeSet 2 with a createForeignKey tag.  You can often get by with modifying existing changeSets if you just created them and haven’t committed them by rolling back the change (there is a liquibase rollbackCount command to help with that), modifying the changeSet tag, then re-updating.  As soon as you have committed the change to your source control system, though, you don’t know who may have ran the “wrong” version and you need to just append your changes.


Thanks for the reply.

This sounds like lurking in the background is a suggested best practice for changeset granularity.

Since I’m starting out, and working with throwaway test databases only at the moment, I have lots of flexibility.

Should I be doing a changeset per table?  Per column?  One changeset for a createTable, then another for each foreign key that might reference it?

Thanks again,

You generally want one changeSet per transaction.  Most changes are auto-committing ddl by the database, so that means you should have one change tag per changeSet.

So you would want to create one changeSet for the createTable, and another for the new foreign key that points to it.