Breaking change on how the file name is calculated hence how the checksum is calculated

Environment

Liquibase Version: Upgrade from 4.4.x to 4.5.0 or 4.6.0

Liquibase Integration & Version: micronaut

Liquibase Extension(s) & Version:

Database Vendor & Version: MsSQL

Operating System Type & Version: Docker Linux

Description

Liquibase upgrade should not change the behaviour of file resolution and the way of naming

With micronaut liquibase / liquibase upgrade, the format is changed, hence breaking upgrade and liquibase migration

Expected behaviour

In DATABASECHANGELOG table, filename column, it should not change the way file names are stored with version upgrade. Or it should have flexibility to configure.

Steps To Reproduce

I had micronaut core 3.1.2 hence liquibase library version 4.4.3

Here is the configuration

liquibase:
  datasources:
    default:
      change-log: 'classpath:liquibase-master-changelog.yml'
      drop-first: false

Master yml file as

databaseChangeLog:
  - include:
      relativeToChangelogFile: true
      file: './db/changelog/sprint_8/liquibase-sprint-8-changelog.yml'

sub yaml file

databaseChangeLog:
  - include:
      relativeToChangelogFile: true
      file: './liquibase-entities.sql'

Individual sql files

--liquibase formatted sql
--changeset author:id
...sql query here...

It used to have entry as following Notice the ./ at start.

Now with micronaut upgrade to 3.2.1 hence liquibase library version 4.6.1

The original configuration does not work. It throws following error

Caused by: liquibase.exception.ChangeLogParseException: Error parsing classpath:liquibase-master-changelog.yml
	at app//liquibase.parser.core.yaml.YamlChangeLogParser.parse(YamlChangeLogParser.java:88)
	at app//liquibase.Liquibase.getDatabaseChangeLog(Liquibase.java:369)
	at app//liquibase.Liquibase.lambda$update$1(Liquibase.java:224)
	at app//liquibase.Scope.lambda$child$0(Scope.java:177)
	at app//liquibase.Scope.child(Scope.java:186)
	at app//liquibase.Scope.child(Scope.java:176)
	at app//liquibase.Scope.child(Scope.java:155)
	at app//liquibase.Liquibase.runInScope(Liquibase.java:2404)
	at app//liquibase.Liquibase.update(Liquibase.java:211)
	at app//liquibase.Liquibase.update(Liquibase.java:197)
	at app//io.micronaut.liquibase.LiquibaseMigrationRunner.performUpdate(LiquibaseMigrationRunner.java:200)
	at app//io.micronaut.liquibase.LiquibaseMigrationRunner.migrate(LiquibaseMigrationRunner.java:157)
	... 75 more
Caused by: java.nio.file.InvalidPathException: Illegal char <:> at index 9: classpath:liquibase-master-changelog.yml
	at java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182)
	at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153)
	at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77)
	at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92)
	at java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:229)
	at java.base/java.nio.file.Path.of(Path.java:147)
	at java.base/java.nio.file.Paths.get(Paths.java:69)
	at liquibase.util.FilenameUtil.getDirectory(FilenameUtil.java:81)
	at liquibase.changelog.DatabaseChangeLog.include(DatabaseChangeLog.java:572)
	at liquibase.changelog.DatabaseChangeLog.handleChildNode(DatabaseChangeLog.java:365)
	at liquibase.changelog.DatabaseChangeLog.load(DatabaseChangeLog.java:320)
	at liquibase.parser.core.yaml.YamlChangeLogParser.parse(YamlChangeLogParser.java:82)

I have to change it as follows

liquibase:
  datasources:
    default:
      change-log: './liquibase-master-changelog.yml'
      drop-first: false

The issue is, with this is,

It is trying to make an entry as follows Notice the absence of ./

Since old change log already would have ./ in file name, it will try to make a new entry. And the migration will fail.

So either, don’t change the file name creation or allow to configure names.

Related question in micronaut issues

Link

[nvoxland]

Yes, that is what I mean, @akshayvadher. Liquibase will treat those two as identical.

The path is not included in the MD5 sum so that will not be impacted either.

[akshayvadher]

I haven’t checked with the new release, I am just assuming.

So are you saying that even though the old change log has ./db/abc/path as filename (already inserted in DB), while comparing with new version, even though new version will try to set db/abc/path, the new version will consider old and new both as the same path names?

Will it also consider MD5 checksum to be equal?