I’m doing some testing prior to implementing Liquibase into our process and I found that tagging works in an unexpected way. I’ve generated a baseline changelog to bootstrap a new DB and have applied it to a new mysql instance, then used the tag command to tag the last applied changeset as “baseline”.
I then wrote a test changelog to test updating from the baseline point onwards; however I got the contexts pattern wrong and no changesets were actually applied (liquibase still ran successfully though). When I tagged the DB following the update, it overwrote the “baseline” tag that had been applied to the last changeset from the baseline DB changelog.
I don’t expect this to be a huge problem as we go forward, but it’s something that I didn’t expect and ideally I’d like to avoid. I did write a script to check if the tag for the last changeset is NULL and only apply a tag if that is the case, but it feels a bit hacky. Is there any way to prevent Liquibase from overwriting the most recent tag if no new changesets have been applied?
Is it expected behavior that the new tag overwrites the previous tag ?
I have a use case wherein I need two consecutive tags applied one after the other… Is it not supported ?
This is working exactly as documented. It depends on whether you are using the “tag” command, or using the “tagDatabase” change-type.
When you use the “tag” command, it not executed as part of a new changeset, so it updates the most recent changeset row in the databasechangelog table, possibly overwriting the previous tag value. From the documentation:
“…by adding the tag to the last row in the DATABASECHANGELOG table.”
When you use the “tagDatabase” change-type, it is executed as part of a new changeset, so it adds a new row to the databasechangelog table, and does NOT overwrite the previous tag. From the documentation:
“…it adds a new row to the DATABASECHANGELOG table.”
For me, the “tagDatabase” change-type is the preferrable way to use tags, coded into the changelogs.
In the “tag” command there is an optional parameter called “—add-row”, however, it is a Pro feature.
While I understand that it has some business implications, such features should be available in open source version too to improve adoption of Liquibase
