Liquibase 4.17.2 incorrectly calculates relative file paths

[xak2000]

At the moment the current spring-boot 3.0.5 branch uses Liquibase 4.17.2.

This version contains a bug: it incorrectly calculates relative paths in changesets (when relativeToChangelogFile="true").

I described the behavior here: liquibase/liquibase#2281 (comment).

Basically, when you have a changeset like this:

<loadUpdateData tableName="country" primaryKey="id" file="data/country.csv" relativeToChangelogFile="true">

With these file locations:

src/main/resources/db/changelog/db.changelog-2.0.xml
src/main/resources/db/changelog/data/country.csv

Then Liquibase 4.17.2 for some reason adds ../ before the path, so the resolved path to data/country.csv becomes incorrect and migration fails.

Looks like this problem is fixed in 4.18.0. At least with this property <liquibase.version>4.18.0</liquibase.version> the same changeset works fine. But I'm not sure what commit exactly fixes this problem (quick diff between 4.17.2..4.18.0 doesn't show it to me).

I know that usually there is no dependency version upgrades in minor spring-boot versions and also I'm not sure what other consequences of updating 4.17.2 to 4.18.0 could be (something is fixed, but something other is probably broken, as usual). So I'm not suggesting to upgrade the version of Luquibase in spring-boot 3.0.6.

I just raised this issue to let the spring-boot team be aware of this problem. Maybe it's worth to add the warning to the 3.0 migration guide or you will decide to do some other cool thing.

I'm in the process of the migration of the application that works fine with sb 2.7.10 to sb 3.0.5 and was very surprised by this behaviour of Liquibase 4.17.2.

Also, when I investigated this problem I found this PR liquibase/liquibase#3355 that fixes another problem. Looks like Liquibase starting from 4.17.x saves the path of migration to DATABASECHANGELOG table together with ./ (if it is present in the xml like this <include file="./changelog-2.xml" relativeToChangelogFile="true"/>). In 4.18 this problem is fixed. But if someone will run such migration the 1st time on 4.17.x then on 4.18.x it will have a different ID (migration ID includes file name and path), and will be runned again. The same is true if user will 1st time run migration on a version before 4.17 and then on 4.17.x. This is even worse than the problem I encountered because it could accidentally run some migration the 2nd time. So, looks like 4.17.x is pretty problematic version. And at the same time this is the version most users will get on migration to spring-boot 3.0. :(

[wilkinsona]

Thanks for the heads-up, @xak2000. I've added a section to the migration guide as you suggested. It links back to this issue. It might be worth reporting your experience to the Liquibase maintainers. Perhaps they would consider another 4.17.x release to ease the migration. If such a release happens, we'd pick it up as part of our usual maintenance process for 3.0.x.

[nvoxland]

Spring boot 3.1.0 will ship with the fixed Liquibase 4.20.0, correct?

spring-boot/spring-boot-project/spring-boot-dependencies/build.gradle

Line 804 in d4107a8

library("Liquibase", "4.20.0") {

[wilkinsona]

Yes, that's right @nvoxland. We're also still maintaining Spring Boot 3.0.x. A Liquibase 4.17.x maintenance release that we can pick up in a Spring Boot 3.0.x maintenance release would be much appreciated.

Having written this, I've just seen liquibase/liquibase#4147 (comment). +1 to what @xak2000 said there.