0

We're using Liquibase to handle our DB Schema changes. As we already have quite a large set of ChangeLogs distributed over multiple files, arranged in a complex folder structure, there sometimes rises the need or the desire to make some refactorings that would influence the meta information in the DatabaseChangeLog table.

What is the recommendation for such refactorings? Can I use Liquibase itself to update the DatabaseChangeLog entries or will I run into caching issues?

A simple example to make my case clearer:

  • I have created a new changeLog file test/changeLog.xml with the default logicalFilePath containing a few changeSets
  • As the file grows bigger, I'd like to split it up into multiple files, move them around in some sub folders and explicitly set the logicalFilePath attribute to 'myChanges' to group them
    • As these changes have already run, I would have to update the DATABASECHANGELOG.FILENAME field, otherwise Liquibase will think that i have introduced new change sets
    • I would need to run an UPDATE DATABASECHANGELOG set FILENAME='myChanges' WHERE FILENAME='test/changelog.xml'
  • Of course, I want to do this in an automated way. What's the best way to do it? Can I use Liquibase itself? Or do I need to update DATABASECHANGELOG in another way (JDBC or whatever) BEFORE I run Liquibase with the new structure?

Thanks for a feedback!

Some follow up:

Sometimes it's just unfortunate that change sets cannot be adapted. Consider the following case:

  • We created a new table with VARCHAR2(255 byte)
  • Everything was fine, table was deployed and populated with data
  • I introduced an embedded H2 database for testing that wouldn't understand "255 byte", but only 255. For the original database, changing it to VARCHAR(255) wouldn't make a difference, but it would change the checksum of the changeset and lead to a Liquibase error.
  • Dropping and recreating the table isn't an option either as the table is already populated with data
  • Using plain Liquibase, I would end up with a solution like creating a new table, moving over my data, deleting the old table and renaming the new one...
mmey
  • 1,545
  • 16
  • 24

1 Answers1

2

There is no support in Liquibase for refactoring changelog files. It normally expects you to just leave things the way they are once they've been run to minimize unexpected differences.

If you are wanting to move things around, the steps you outlined are what you would need to do. LogicalFilePath will help, and updating the databasechangelog.filename column should be all you need to do.

You will need to update the filename path before you run liquibase the first time after reorganizing the files or it will execute the changeSets again. Liquibase looks at the changelog table and changelog file immediately on startup, so you will need to update the filename column outside of Liquibase.

Nathan Voxland
  • 15,453
  • 2
  • 48
  • 64
  • Hi Nathan. Thanks for your feedback! I added a sample use-case to my description to show that sometimes it's unfortunate not being able to change a changeset (e.g. in cases it helps syntactically but wouldn't actually change existing structures on DBs where it already run). 2 questions: Could I use a separate Liquibase run to update the DatabaseChangeLog or would it mess up Liquibase if a changeLog is messing around in that table? And what would you think of an extension to Liquibase like a changeLog attribute "canReplaceChecksum=xyz" or something like that for appropriate use cases? – mmey Sep 23 '14 at 21:45
  • there is a tag you can add to your changeSets when you purposely change the changeSet and want to tag the change as OK. I think that is the same as your canReplaceChecksum – Nathan Voxland Sep 24 '14 at 14:56
  • It should work to have a separate liqubase run that actually updates the changelog table. Liquibase just reads it at the beginning so anything you to do it after startup should be fine. – Nathan Voxland Sep 24 '14 at 14:59
  • Cool, wasn't aware of the validCheckSum tag. Found some more info at http://forum.liquibase.org/topic/understanding-validchecksum, that's pretty much what I meant. I think that approach is useful if working with a few isolated changeSets and the other approach (updating DatabaseChangeLog with Liquibase before running the actual changeLog) may be helpful for bigger migrations like filenames of a lot of files. Thanks again for the feedback and keep up the good work! – mmey Sep 24 '14 at 20:11
  • @NathanVoxland, I am not sure I get your answer after reading all your comments. In the answer you are saying that updating logicalFilePath and databasechangelog.filename should be enough, but then you are referring to , which seems that its another step that is missing in your answer. – yuranos Feb 18 '17 at 06:34