After experimenting for a while, I finally came to the conclusion that the tagDatabase action does not do what I want/hope/expect it to do. The problem is that it applies tags based purely on the date that changesets were applied, rather than the actual order in which they were applied. This works fine if there is only one tag operation per update, but if tagDatabase gets called multiple times during the same run, the last tag wins.
For example, consider a changelog containing the following changesets:
- create table X
- tag “v0”
- create table Y
- tag “v1”
If I run this on an empty database, I expect the first statement to be tagged “v0”, the second and third to be tagged “v1”, and the fourth to be untagged. Instead, the first three are all tagged “v1”, making it impossible for me to roll back to the point after I create table X but before I create table Y (using tags, that is).
Is this a bug? Looking at the generated SQL, it appears there might be an easy fix. Instead of updating ALL rows for the given date:
UPDATE DATABASECHANGELOG SET TAG = ‘v1’ WHERE DATEEXECUTED = (SELECT MAX(DATEEXECUTED) FROM (SELECT DATEEXECUTED FROM DATABASECHANGELOG) AS X);
what if it only updated those rows with NULL tags:
UPDATE DATABASECHANGELOG SET TAG = ‘v1’ WHERE DATEEXECUTED = (SELECT MAX(DATEEXECUTED) FROM (SELECT DATEEXECUTED FROM DATABASECHANGELOG) AS X) AND TAG IS NULL;