Do not ignore unknown change types when no attributes are specified

[KushnirykOleh]

Search first

• I searched and no similar issues were found

Description

Liquibase will fail validation when it hits a change type it doesn't recognize, but NOT if there are no attributes on the change.

With XML, the liquibase XSD adds an extra layer of validation that disallows unknown change types, but using the ext or another "allow anything" schema will get you past that layer, to the cross-changelog-type validation layer where the problem is. If you are not using an XML based changelog, you see this more directly and easily.

Example problem changeset:

    <changeSet id="sqlTest" author="system">
        <ext:invalid>
            CREATE TABLE PUBLIC.sqltest (id INT)...
        </ext:invalid>
    </changeSet>

NOTE: If the changeset would have been:

    <changeSet id="sqlTest" author="system">
        <ext:invalid table="sqltest">
            CREATE TABLE PUBLIC.sqltest (id INT)...
        </ext:invalid>
    </changeSet>

it would have correctly failed the with an "unknown change type 'invalid'" validation error.

Steps To Reproduce

See description

Expected/Desired Behavior

Such changeTypes shouldn't be run saying changes are deployed, when they are not, this is even worse than if Liquibase throw error but actually deploys changes as it creates hard-to-find issues.

Liquibase Version

4.20

Database Vendor & Version

any

Liquibase Integration

No response

Liquibase Extensions

No response

OS and/or Infrastructure Type/Provider

reproduced on Windows 10 and Ubuntu

Additional Context

ticket referring mongo change where issue was found https://datical.atlassian.net/browse/DAT-13999

Are you willing to submit a PR?

• I'm willing to submit a PR (Thank you!)

[nvoxland]

I think the problem code is at

liquibase/liquibase-standard/src/main/java/liquibase/changelog/ChangeSet.java

Line 560 in 42c45a6

if (value.getChildren().size() > 0 && ChangeLogParserConfiguration.CHANGELOG_PARSE_MODE.getCurrentValue().equals(ChangeLogParserConfiguration.ChangelogParseMode.STRICT)) {

where we only throw the error if the child node has attributes.

I'm not sure the correct fix off hand, because we have a feature that extensions can be looking for custom attributes on the changeSet object and we don't know what those could be. And parsed-node structurally (because of yaml/json) there isn't a great difference between a nested key/value element and an attribute.

So it's possible this will not be an isolated fix, but hard to know until someone gets into the code and tries.