Create Index with with space in the column name

Liquibase Users
#1

Hello,

I am migrating from version liquibase-core:jar:3.6.3 to liquibase-core:jar:3.8.9 and one of my existing changeset is failing to be executed during my integration tests.

Index clause:

<createIndex tableName="table" indexName="index_name_idx">
       <column name=" column"/>
 </createIndex>

Please note that by mistake, I had a space at the beginning of the column name " column". While running this command using liquibase 3.8.9 produce the following SQL:

CREATE INDEX "index_name_idx" ON public.table(" column")

While running it with the previous version:
CREATE INDEX index_name_idx ON public.table(column)

At this point, the only option I see is to:

  • Put failOnError=false on the original changeset.
  • Add a new changeset with the fix & preconditions to preventing this to be executed if previous changeset was executed.

Do you see a different solution ?

Thank you !

#2

Hi @Gemoga,

Another possible solution would be to just change the existing changeset to remove the space in the column name. Normally this would cause an exception to be thrown when running liquibase against any database that already had that changeset run on it due to the checksum changing, but you can sort that by adding the validCheckSum tag to the changeset with the value of the checksum for the original version of the file (with the space before the column name). So the changeset would end up looking something like this:

<changeSet author="author" id="your_id">
    <validCheckSum>8:4203109b8336d525e7cc69133285de63</validCheckSum>
    <createIndex tableName="table" indexName="index_name_idx">
        <column name="column"/>
    </createIndex>
</changeSet>

The easiest way to find out what the original checksum was is to just look in the databasechangelog table on a database where the original changeset had been run and find the row for that changeset and just copy the checksum from there.

I’ve used this trick a couple of times recently to fix changes that had issues like this where there was a small mistake in the original file.

Hope that helps :slight_smile:
Dave

1 Like
#3

Thank you @devdave !

Yes indeed that option is the one I am taking, since for this case semantically the changeset is the same.

Thanks for taking the time to reply.

Gerardo