Removal of redundant / from default value for spring.liquibase.change-log may cause the change log to be reapplied on upgrade

[wilkinsona]

See #20118 (comment) for details.

[xak2000]

I didn't thought this change can break configuration of already existing projects in this way.

I think, it's a dangerous change, then.

Because, just updating the spring-boot version and running the app will lead to all DB changes will be tried to be applied again.

Usually it will be interrupted just by first CREATE TABLE changeset, because the table already exists. But what if someone has changelog, where first changeset is more dangerous? E.g. DROP TABLE IF EXIST (it's unlikely to have a changeset like this, especially ordered first, but who knows what else ways to damage his DB a creative developer can invent).

I'm not sure anymore that this is a good change. :-) It's definitely good for new projects, but can be pretty dangerous for existing projects.

[wilkinsona]

Thanks for your thoughts, @xak2000. I agree that it's good for new projects, but I can't think of a good way to avoid causing problems for existing projects. The only thing that I have been able to come up with is Boot querying the change log history service and somehow figuring out for itself that the changelog has already been applied from a subtly different source path. Even assuming that's possible, I think it would be brittle. A more robust solution would be for Liquibase itself to use a canonical form when determining if a change log has already been applied.