Fixed issue that unique constraint precondition does not honor schemaName attribute on MySQL

[mpvvliet]

Fixes #3977

Impact

• Bug fix (non-breaking change which fixes expected existing functionality)
• Enhancement/New feature (adds functionality without impacting existing logic)
• Breaking change (fix or feature that would cause existing functionality to change)

Description

Things to be aware of

Only for MySQL.

Things to worry about

Additional Context

[mpvvliet]

Figured out how to use the default schema in a precondition. This fixes all problems in #3977 as far as I can see.

[MalloD12]

Hi @mpvvliet,

Thank you for taking the time to create this PR. Code changes look good to me. I have only added a comment to ask you for a little improvement. One other thing I would like to ask you is about tests. I think it would be good if we can an integration test for mssql. It would be simply adding a new changeset in this file src/test/resources/changelogs/mssql/complete/root.changelog.xml. Something like this:

<changeSet id="CHANGESETID" author="CHANGESETAUTHOR">
    <preConditions>
        <uniqueConstraintExists tableName="address" constraintName="uq_address_line1line2"/>
    </preConditions>
    <dropUniqueConstraint tableName="address" constraintName="address"/>
</changeSet>

Thanks in advance,
Daniel.

[mpvvliet]

@MalloD12 happy to add the test. Any reason it's for mssql specifically?

Also, I see changeset 32 adds the constraint and changeset 33 removes it. Given the changes, it seems to me that we would want to execute the test with the constraint present in the DB and the changeset having a <not/> around the precondition. That way, without the code changes, the constraint would not be found, passing the precondition and failing on dropping the constraint, failing the test. With the change, the changeset would not be executed, passing the test.

I'm not too familiar with how these tests work so could be off. :-)

[MalloD12]

Hi @mpvvliet,

I said mssql just because I saw that was the database specified in #3977, but this is a good point. I think it would be better to be more generic and specify this case in the changelog that will be deployed in any DB. This could be src/test/resources/changelogs/mssql/complete/root.changelog.xml. Some integration tests basically deploy a changelog and do specific checks afterward, but in some other cases, we are good enough just knowing a given changelog has been successfully deployed, which means that the given scenarios (changesets) didn't have any issue when they were deployed.

I hope it helps you to have a better (high-level) idea of how these tests work, if not please ask and I'll do my best to give you a better picture of them.

Thanks,
Daniel.

[mpvvliet]

@MalloD12 I refactored the code as per your suggestion and added an integration test. The entire test suite passes in my local setup.

[MalloD12]

Approved.

Looks good to me. Thanks you for addressing the review comments.

Daniel.