1

So, a while back I moved all of our database functions and view to individual files for better change control. Today, I deleted a function and therefore I deleted the file for that function. However, the original changeLog from 2019.Q2.R1 still references the file and liquibase complains that the file does not exist now.

15:39:35 SEVERE 1/29/20 10:39 PM: liquibase: changelogs/catalog/catalog.db.changelog-2019.Q2.R1.xml::US122742.17::vrodrigu: File does not exist: 'functions/update_daily_take_ingest_date_func.sql'

We are following the best practice recommended by liquibase where we have a master changelog file that then includes all of changelog files, one for each new release. The file I deleted is still referenced by an old changelog file catalog.db.changelog-2019.Q2.R1.xml, which as the name implies is from Q2 of last year.

What is the best practice in these situations? Should a file referenced by old sqlFile elements just never be deleted? Should I go back to the old references and eliminate those references? The latter would be changing history and someone looking at that old changelog file wouldn't be the wiser. Is there a flag or attribute I can put on my changelogs so that they don't complain about the file not existing if it's deleted in the future?

Not sure what the best approach is. Thanks in advance for your help!

Victor Rodriguez
  • 75
  • 2
  • 8

1 Answers1

1

The best practice would be to write another changeSet in which you delete the function and add it to your project as a new file.

ChangeLogs and changeSets are supposed to be immutable. This idea is one of the corner stones of Liquibase-like tools. You are supposed only to add new changeSets to alter the existing database structure (even if the changeSets you're adding remove something).

Hence, altering or deleting existing changeSets (or changeLog files) is the opposite of best practice.

htshame
  • 6,599
  • 5
  • 36
  • 56
  • Right, but the purpose of moving the functions and views to individual files was to be able to rely on version control to better control and see the differences from one version to the next. Maybe there's a way to tell liquibase to only ever run a changeSet only once and never check for a checksum variation ever again? – Victor Rodriguez Jan 30 '20 at 20:43
  • Liquibase is supposed to check the integrity of the changeLog, that's why it has a checksum verification. If you want version control, then you should check out Liquibase `tag` and `rollback` features. – htshame Jan 30 '20 at 20:55
  • Hmmmm, so I actually do have `runOnChange="false"`, so there's really a defect. Liquibase should check to see if the `changeSet` has already run FIRST and if so, don't even bother looking for the `sqlFile`. – Victor Rodriguez Jan 30 '20 at 21:04
  • Liquibase JIRA defect created: https://liquibase.jira.com/browse/CORE-3575 – Victor Rodriguez Jan 30 '20 at 21:17
  • hstname, by version control, I mean being able to look at the history of a particular function or view by looking at the version history in git or any other source control tool like you would any other piece of code like java or javascript or anything else. functions are code after all. – Victor Rodriguez Jan 30 '20 at 21:19
  • @VictorRodriguez, As far as I know `runOnChange` defaults to `false` in every changeSet. It does so in order to receive an error about changed checksums and not to be executed again. It doesn't mean that the changeSet will be completely ignored afterwards – htshame Jan 31 '20 at 12:56