Generated Changeset - Attribute 'indexName' must appear on element 'createIndex'

General Discussion
1

I’m upgrading an old app from liquibase 3.5.5 to 4.1.

It includes a section that uses liquibase to generate a diff based upon the Hibernate Entities and the MySql database.

For some reason, the changesets being created by the Diff don’t include an “index name” for Unique Indexes.

if I add the following to my Entity:

@javax.persistence.Index(name = "Peter2ItemIdx", columnList = "name, itemId", unique=true)

It generates a changeset like this:

    <changeSet author="pstiles (generated)" id="1602173067371-1">
    <createIndex tableName="Item" unique="true">
        <column name="name"/>
        <column name="ItemId"/>
    </createIndex>
</changeSet>

Obviously missing an “index name” property of any sort.

If I remove the “unique=true” then the generated changeset is better:

<changeSet author="pstiles (generated)" id="1602231213650-1">
    <createIndex indexName="Peter2ItemIdx" tableName="Item">
        <column name="name"/>
        <column name="ItemId"/>
    </createIndex>
</changeSet>

I’ve tried with 4.0 and 4.1 and appear to get the same results.

Any suggestions would be appreciated.

2

Hi @pstiles_edwtech!

There have been significant changes from 3.x to 4.0. I would try 2 things:

Thanks,

Ronak

3

Ok. Code modifications made to support 3.10.2
run the same tests as above, and the same behaviour is exhibited by 3.10.2

I tried different hibernate syntax in my entity,

uniqueConstraints = { @UniqueConstraint(name = "Peter2ItemIdx", columnNames = {"name", "itemId"}) }

which, again generated the changeset sans indexname

<changeSet author="pstiles (generated)" id="1602257637984-1">
    <createIndex tableName="Item" unique="true">
        <column name="name"/>
        <column name="ItemId"/>
    </createIndex>
</changeSet>

Now i’m getting worried. I’d best check our old codebase using 3.5.5… That’ll be after the weekend as its home time now.

4

I’m comparing a MySql 5.7 database (using Inno as you’d expect). The “dialect” is “MySQL5InnoDBDialect”.

My production application has 200 customer databases, and so I have to have some form of automated database management. I also have a swatch of historical differences between customer databases that no matter how much I beg I don’t have the budget to sit down and fix, so I have to use the Diff capability of liquibase to keep the databases inline as a number of the production databases have extra tables/indexes/etc :frowning:

If I include

typesToInclude.add(Index.class);

and

typesToInclude.add(UniqueConstraint.class);

in my diff, the generated changeset includes a valid “addUniqueConstraint” sections for the new “unique indexes” in my Entities.

If I don’t include the

typesToInclude.add(UniqueConstraint.class);

in my diff then the generated changeset includes an invalid “createIndex” section for the new “unique indexes” in my Entities, as described above: missing the “index name” property.

This behaviour appears constant for me no matter what versions of Liquibase (using 3.5.5, 3.10.2 and 4.1.0).

HOWEVER 4.1.0’s abherrent behaviour:

When I include both clauses:

typesToInclude.add(Index.class); 
typesToInclude.add(UniqueConstraint.class);

in my diff for 4.1.0 it goes wild and includes “addUniqueConstraint” sections for ALL the “unique indexes” in my Entities, not just the new ones.
For some reason it seems to not be able to see that the constraint already exists :frowning:

But if I only include the

typesToInclude.add(Index.class);

in the diff, then it only adds “createIndex” sections for the “new” indexes. However, as noted above, when the indexes are “unique” it misses the name off.

So, with prior versions I would include both Types in my diff and I’d end up with a working script. But with 4.1 I can’t get a working script - I’m either missing the index name off or I’ve got loads of extra “addUniqueConstraints” that blow up when they run.

Is there something I’m doing wrong, as I can’t seem to get an “index name” on a generated “create index” change for a unique index no matter what versions I throw at it I’m sure this can’t work like this for Everyone can it?

Given this behaviour I can’t update our system to Liquibase 4+.