Include columnDataType in generated setColumnRemarks changesets

[coylecullen]

Description

In 4.6.2, changesets generated due to differences in column remarks would not include the columnDataType attribute which is needed for some databases (mysql for sure).

This change adds the datatype to the generated Change if it is available.

Repo Steps

If you create two tables on different databases with different comments like this:

create table intuser_db.test_table (id int, name int COMMENT 'table 1');
create table intuser_db2.test_table (id int, name int  COMMENT 'table 2');

then run liquibase diff-changelog between the intuser_db and intuser_db2 databases, the generated changeset used to look like this:

<changeSet author="nathan (generated)" id="1640195447990-1">
        <setColumnRemarks columnName="name" remarks="table 2" tableName="test_table"/>
    </changeSet>

without the columnDataType attribute. If you tried to run this changeset against a mysql database, it would fail with a "columnDataType is required" error.

With this change, the generated changest looks like this:

<changeSet author="nathan (generated)" id="1640195447990-1">
        <setColumnRemarks columnDataType="int" columnName="name" remarks="table 2" tableName="test_table"/>
    </changeSet>

which cleanly applies to mysql and other database types.

---

Dev Handoff Notes (Internal Use)

Links

• Fixed Issue: Stand alone PR
• Test Results: https://github.com/liquibase/liquibase/pull/2188/checks

Testing

• Steps to Reproduce: See above
• Guidance:
  • Impact: Changes how the setColumnRemarks change is generated for all databases, so it always includes the columnDataType. That attribute is ignored on databases that don't need it

Dev Verification

Ensured the steps listed above work locally.

Test Requirements (Liquibase Internal QA)

You will require 2 MySQL database instances.

Setup

On first database instance execute create table test_table (id int, int_col int COMMENT 'database 1', char_col char(50) COMMENT 'first test');

On second database instance execute create table test_table (id int, int_col int COMMENT 'database 2', char_col char(50) COMMENT 'second test');

Manual Tests

Verify diff-changelog generates columnDataType parameter.

• liquibase diff-changelog --changelog-file lb2199-changelog.xml
• generated changelog should contain 2 changesets with tag
  • first changeset should contain columnName="int_col" columnDataType="int(10)" arguments
  • second changeset should contain columnName="char_col" columnDataType="char(50)" arguments

Verify update is successful with generated changelog.

• liquibase update --changelog-file lb2199-changelog.xml
• int_col in first database instance now has database 2 remark
• char_col in first database instance now has second test remark

Repeat all tests for json, yaml and sql changelog formats.

Automated Tests

No new functional tests required for this fix.

┆Issue is synchronized with this Jira Bug by Unito

[molivasdat]

Hi @coylecullen Thanks for creating this PR.
Based on the code change, it appears that there are different column remarks on the two different profiles(databases).
QA and US in your system. Is that correct?

A member of the Liquibase team will take a look at your contribution and may suggest:

• Changes based on guidelines for PR submission
• Additional tests (unit and/or integration) and/or Test Harness Tests
• Provide other feedback, like requesting changes.

The PR will be prioritized according to our internal development and testing capacity.

We’ll let you know when it’s ready to move to the next step or if any changes are needed.

[nvoxland]

After taking a look at this PR and the #2152 issue it was listed as fixing, I ended up rewriting this PR's description to be more stand-alone.

The null pointer exception in 2152 was handled separately, but this still fixes a needed problem so this should explain it for the remaining portion better.

I did find that I had to update the generated changelog xsd version to one that supports the columnDataType attribute, so that is in there there too.

I also merged origin/master into your fork so it builds better now