CORE-2321 Liquibase tag command tags too much, CORE-842 #392
Conversation
|
This is working fine for me as implemented as far as rolling back to a tag is concerned. However, I noticed differences in the number of records updated, depending on the accuracy of the data type chosen for DATEEXECUTED. Now I'm thinking, is there any reason not to use MAX(ORDEREXECUTED) in preference to MAX(DATEEXECUTED). That would seem to guarantee exactly 1 record is updated rather than a varying number. |
|
On a further review, it seems possible that the INSERT statement generated by MarkChangeSetRanGenerator obsoletes the UPDATE statement generated by TagDatabaseGenerator. Thoughts? |
|
I found that the MarkChangeSetRanGenerator could be improved to always tag successfully ran changes, eliminating the need for TagDatabaseChange to generate any SQL statements. I also found that the TagDatabaseGenerator was used outside the scope of change log execution, and under that scenario it was necessary to run the complex update statement to identify and update the last change set executed. Therefore I thought it would be prudent to implement both ideas. The pull request has been updated accordingly. Looking forward to feedback. |
…lated SQL statements
responsible for tagging when executing a change log, while still allowing the database to be tagged outside of that scenario using the necessary update statement with subqueries and aggregate expressions. This can improve performance of executing change logs by eliminating the need to execute unnecessary update statements with subqueries and aggregate expressions. Improve the update statement to use the more-unique ORDEREXECUTED column rather than potentially less unique DATEEXECUTED to ensure that only the minimum number of records get updated.
|
I believe this also resolves the following issue |
mches
changed the title
|
I merged the pull request into master since it's more than I'd like to do in a patch release in 3.3.x. Your pull request had a lot of good improvements, but the logic in TagDatabaseGenerator wasn't quite correct because you cannot rely on orderexecuted to always be increasing. There are times (especially when running updateSql) where we cannot know where to start orderexectued so it just restarts at zero. Orderexecuted is guaranteed to be increasing within a single update run, but isn't necessarily increasing across update runs. I merged your request into master along with an additional fix to change the TagDatabaseGenerator logic for oracle, mysql, mssql, postgres, informix and db2 to take orderexecuted and dateexecuted into account. As a fallback it just uses dateexectuted until other SQL for other databases can be created and tested. |
CORE-2321 Liquibase tag command tags too much
I've tested this with Microsoft SQL Server 2008 R2 using DATEEXECUTED with data type date (no hours, minutes, seconds, or fractional seconds).