Liquibase rolls back a change whose exectype is "MARK_RAN"

Liquibase Development
1

Hi,

Liquibase version: 4.4.1
Database: Derby 10.13.1.1

I ran into an issue where Liquibase rolls back a change whose exectype is “MARK_RAN”. It is set as “MARK_RAN” because the precondition for the change failed.

The custom rollback for the change is failing because it was attempting to rollback something that wasn’t applied.

I did a search and it looks like this issue has been reported before:

In one of the links, nvoxland said that:

The change does get marked as MARKED_RAN, which the code is currently designed to ignore on rollback

But seems now it is not getting ignored? Has anybody experienced it, and how did you handle it?

Thanks.

2

When you mark something as “RAN” it implies that the sql in the changeset was actually executed, so the rollback instructions should still be able to be applied successfully.

Can you provide an actual example?

3

Hi Daryl,

This is my use case:

<?xml version="1.0" encoding="UTF-8"?>

<databaseChangeLog
        xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog

   http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-3.8.xsd">

    <changeSet author="mqtpersonal" id="1">

        <preConditions onFail="MARK_RAN" onError="HALT"
                       onFailMessage="Columns are already BIGINT."
                       onErrorMessage="An error occurred while checking precondition_1.">
            <customPrecondition className="sample.modules.preconditions.precondition_1"/>
        </preConditions>

        <addColumn tableName="SAMPLE_TABLE">
            <column name="NEWCOLUMN" type="BIGINT" defaultValueNumeric="0" valueComputed="OLDCOLUMN">
                <constraints nullable="false"/>
            </column>
        </addColumn>

        <dropDefaultValue tableName="SAMPLE_TABLE" columnName="NEWCOLUMN"/>

        <dropPrimaryKey tableName="SAMPLE_TABLE"/>

        <addPrimaryKey tableName="SAMPLE_TABLE" columnNames="MISC, NEWCOLUMN" constraintName="PK_SAMPLE_TABLE"/>

        <dropColumn tableName="SAMPLE_TABLE" columnName="OLDCOLUMN"/>

        <renameColumn tableName="SAMPLE_TABLE" oldColumnName="NEWCOLUMN" newColumnName="OLDCOLUMN"/>

        <rollback>
            <addColumn tableName="SAMPLE_TABLE">
                <column name="NEWCOLUMN" type="INTEGER" defaultValueNumeric="0" valueComputed="OLDCOLUMN">
                    <constraints nullable="false"/>
                </column>
            </addColumn>

            <dropDefaultValue tableName="SAMPLE_TABLE" columnName="NEWCOLUMN"/>

            <dropPrimaryKey tableName="SAMPLE_TABLE"/>

            <addPrimaryKey tableName="SAMPLE_TABLE" columnNames="MISC, NEWCOLUMN" constraintName="PK_SAMPLE_TABLE"/>
            <dropColumn tableName="SAMPLE_TABLE" columnName="OLDCOLUMN"/>

            <renameColumn tableName="SAMPLE_TABLE" oldColumnName="NEWCOLUMN" newColumnName="OLDCOLUMN"/>
        </rollback>
    </changeSet>
</databaseChangeLog>

It changes a column’s data type from INT to BIGINT (Derby does not support changing the data type directly). If something goes wrong in the system, it changes the data type back from from BIGINT to INT.

There is a precondition that checks if the columns are not yet BIGINT. If they already are, then the precondition fails and the changeset will be marked as “MARK_RAN”. The problem is when a rollback is triggered, it will attempt to copy existing BIGINT values that may be out of range back to an INT column. This results in an error: Unexpected error running Liquibase: The resulting value is outside the range for the data type INTEGER.

I think that since the precondition failed and was set to “MARK_RAN”, it shouldn’t have been running the rollback as there is nothing to rollback.

4

With regards to this, since the “MARK_RAN” was the result of an “onFail” event, shouldn’t it be interpreted that some queries might not have been executed because of the failure?

5

Can anybody help? I also found an open bug report on this issue:
https://liquibase.jira.com/browse/CORE-1138