Liquibase - Mass Applying ChangeSets where packages change over time

1
votes

Given a scenario such as:

  • changeSet 1: create table A
  • changeSet 2: populate table A
  • changeSet 3: create package B referencing table A
  • changeSet 4: update data in table A using procedure in package B
  • changeSet 5: add column to table A
  • changeSet 6: revise package B to consume new column

If I was developing and applying these changes to the DB serially over time as they were committed, it should work fine.

However, if a new developer came along and tried to roll the changes from the beginning wouldn't it fail? Since liquibase is looking only at the present state of the files, wouldn't changeSet 3 fail because the latest version of package B contains a reference to a column in table A that doesn't exist yet?

How can this be addressed? Is there a way to get Liquibase to pull changeSets based on repo commit or tag? Or would you have to write a wrapper to serially check out all your release tags and apply liquibase to each one?

The only thing I can think of is to prevent developers from writing DDL/DML that references the packages, and not worry about interim package state. But things would also fail if a developer wanted to use updateCount 3 from the beginning.

1
plsqlversionliquibase
For changeSet3 and changeSet6 - do they reference the same file with package via runOnChange? – dbf

1 Answers

1
votes

Yes, if your changelog is using procedure B as part of the update process, you can run into problems if you are editing the SQL of the procedure file so that it is different from one run to the next.

The easiest approach is to not edit the procedure sql, but rather have changeSet 3 reference a packageb-1.sql CREATE PROCEDURE file, and then have changeSet 6 reference a different packageb-2.sql ALTER PROCEDURE file. You end up with more files and you can't do a version control-level diff, but the procedure created in changeSet 3 will always be the same, regardless of when you run liquibase.