It is no longer possible to create calculated columns on mssql

Environment

Liquibase Version: 4.6.1

Liquibase Integration & Version: maven

Liquibase Extension(s) & Version:

• liquibase-hibernate5: 4.6.1

Database Vendor & Version:

• Microsoft SQL Server Developer (64-bit) 15.0.2080.9

Operating System Type & Version:

• Windows 10 Pro (10.0)

Description

Liquibase 4.6.1 (and lower?) seems to require a value for the type property for the column specified in a addColumn change, this prevents the possibility to create a computed column on mssql as the generated SQL statement leads to a syntax error

Steps to reproduce

The following changeset worked with Liquibase 4.3.5:

<changeSet id="20200123095600-1" author="me" dbms="mssql">
    <addColumn tableName="event">
        <column name="payload_id AS JSON_VALUE(payload,'$.id')"
                       type=""
                       computed="true">
        </column>
    </addColumn>
    <createIndex tableName="event" indexName="idx_payload_id">
        <column name="payload_id"/>
    </createIndex>
</changeSet>

But, 4.6.1 gives me the following error:

liquibase.exception.ValidationFailedException: Validation Failed:
     1 changes have validation failures
          columnType is empty, config/liquibase/changelog/20200123110200_create_index_entity_Event.xml::20200123095600-1::me

It complains that the type attribute of the column specified in the addColumn change is empty.
If I specify the correct type as follows…

        <column name="payload_id AS JSON_VALUE(payload,'$.id')"
                       type="nvarchar(4000)"
                       computed="true">
        </column>

…Liquibase compiles it to the following SQL statement, which leads to a syntax error on mssql:

[Failed SQL: (102) ALTER TABLE event ADD payload_id AS JSON_VALUE(payload,'$.id') nvarchar(4000)]

Expected/Desired Behavior

I expect the pre-existing addColumn block for creating computed columns on mssql to be working even in 4.6.1, either without specifying the type property or by correctly specifying it and having the generated SQL statement to be correct.

[yodzhubeiskyi]

This issue is fixed by #2340

[nickshoe]

Thanks @yodzhubeiskyi, I’ll try it out.