Add changelogSyncToTag and changelogSyncToTagSQL commands

[suilven]

The changelogSync and changelogSyncSQL commands are very valuable when adding Liquibase support to an existing, unversioned database. The changelogSync command adds the databasechangelog table to the schema and marks all the changeSets in the changeLog as ran. Often, however, there are different versions of the schema already in the wild, so the ability to mark as ran only those changeSets up to (and including) a given tag would be very useful.

Use Case (copied from comments)

Hi mariochampion

• I've just created a PR with my proposed changes ( [1133] Add changelogSyncToTag and changelogSyncToTagSQL commands #1138 ). No modification of the changeSets is required. Imagine you had different versions of the same schema used in several different production databases. You want to start using Liquibase to version those schemas. At some point you generated a Liquibase changeLog for your schema and added a tag. Lets say that was version 1.0. You've been updating your changeLog and you have tags at version 1.1, 1.2, 1.3, etc. You're now at version 2.0. You have a production database which has a schema equivalent to version 1.2 of your changeLog but if you run changeLogSync with your latest changeLog, it will mark all changeSets up to the 2.0 tag as ran in the database. So this change allows you to stop at the version 1.2 tag when marking changes as ran.

Automation Test Requirements

• Create a changelog to the specifications in the "Use Case."
• Execute a deploy to a database with version 1.1 and 1.2
• Execute a changelogSyncToTagSQL with 1.2 and verify that there are no changes to make.
• Execute a changelogSyncToTag with 1.2 and verify the DBCL is not updated with 'ran' for changes associated with tag 1.3.
• Execute an changelogSyncToTagSQL with 1.3 and verify there are changes to make.
• Execute a changelogSyncToTag with 1.3 and verify the DBCL is updated with 'ran' for changes associated with tag 1.3.

[mariochampion]

hey @suilven -- intriguing idea. Are you thinking something like running generatechangelog, then on your own you add tags to the changesets (ie, tagDatabase tag=someversion) that mark different versions in the wild.

then adjusting your connection to point to a, say, v3 of the db, and run changelogSync --synctotag=v3 (or something like this?)

[suilven]

Hi @mariochampion - I've just created a PR with my proposed changes. No modification of the changeSets is required. Imagine you had different versions of the same schema used in several different production databases. You want to start using Liquibase to version those schemas. At some point you generated a Liquibase changeLog for your schema and added a tag. Lets say that was version 1.0. You've been updating your changeLog and you have tags at version 1.1, 1.2, 1.3, etc. You're now at version 2.0. You have a production database which has a schema equivalent to version 1.2 of your changeLog but if you run changeLogSync with your latest changeLog, it will mark all changeSets up to the 2.0 tag as ran in the database. So this change allows you to stop at the version 1.2 tag when marking changes as ran.

[liquibot]

➤ Erzsebet Carmean commented:

@suilven, hello! Thanks for filing the issue and creating a PR.

-erz (XDelphiGrl)

[liquibot]

➤ Erzsebet Carmean commented:

Can the Community Engagement team please assess risk for the PR? This will allow me to give QA estimates. Thanks!

CC ::
[~accountid:59f7ce6d93915e620920523a]

[liquibot]

➤ Mario Champion commented:

hey internal reviewers, the linked PR is against master, so this ticket gets resolved with that one in the 4.0 beta 2 release.

[liquibot]

➤ Erzsebet Carmean commented:

🚩 Flag added

I'm flagging this for discussion in our internal Conditioning meeting. I'm unclear as to the risk level and QA involvement.

-erz (@ XDelphiGrl)

CC: [~accountid:557058:c8f0b24d-f02f-431c-8842-fd9c929dfbf2]
CC: [~accountid:5d937e71f5d3c10d8bfd351d]