How to work with liquibase, a concrete example

Question

Following the quickstart on liquibase i've created a changeset (very dumb :) )

Code:

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

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

    <changeSet id="1" author="me">
        <createTable tableName="first_table">
            <column name="id" type="int">
                <constraints primaryKey="true" nullable="false"/>
            </column>
            <column name="name" type="varchar(50)">
                <constraints nullable="false"/>
            </column>
        </createTable>
        <createTable tableName="new_table">
            <column name="id" type="int">
                <constraints primaryKey="true" nullable="false"/>
            </column>
        </createTable>
    </changeSet>

</databaseChangeLog>

I've created a clean schema and i've launched the migrate command.

Liquibase created the database, with the support tables databasechangelog and ..lock.

Now how i can track the changes?? i've modified the changeset adding a new createTable element but when i try the command "update" liquibase tells me this

Migration Failed: Validation Failed:
     1 change sets check sum

so i don't think to have understood the way to work with liquibase.

Someone may point me to the right direction??

Thanks

Solution 1

You should never modify a <changeSet> that was already executed. Liquibase calculates checksums for all executed changeSets and stores them in the log. It will then recalculate that checksum, compare it to the stored ones and fail the next time you run it if the checksums differ.

What you need to do instead is to add another <changeSet> and put your new createTable element in it.

QuickStart is good readin' but it is indeed quick :-) Check out the full manual, particularly its ChangeSet section.

Solution 2

This currently accepted answer is slightly out of date based on changes in Liquibase 2.x. In the 2.x version, Liquibase will still fail if the md5 checksum has changed for a changeset, but you can specify the runOnChange attribute if you want to be able modify it.

From the documentation:

runOnChange - Executes the change the first time it is seen and each time the change set has been changed

Solution 3

If it's a change to a changeset that basically has already been done, you can manually modify the database so that its md5 for that changeset matches the new one. Good for minor textual changes. Or you can delete that changeset row from your table.

Comments

[apelliciari]

that's clear now, i didn't found and read that page in the manual :)

[Shaun]

This answer should be considered in conjunction with the accepted answer.. runOnChange will let you modify an existing change set. The accepted answer is right in saying you shouldn't change existing changesets, but there are times you might need to, and your policy should allow for it.

[Shaun]

There are times you need to modify posted ChangeSet elements. See the runOnChange answer Javid gave for more information. We used to do the "never change" thing but found it to be a very hard policy to stay with when there are times that you need to update the changeSet (and that WILL happen to you as you get more involved with liquibase). Keep options open.

[Biggy_java]

Thanks! this is the accurate answer

[Patrick M]

"times you might need to", such as in a development environment and making iterative changes during development. It would sure look weird if your first deployment to a prod environment had a fistful of related, overlapping and contradictory changesets.

[Patrick M]

I do this a lot, but I find it's better to delete the record and unwind the change manually than to mess with the md5sum. Only once when an app DB had been modified by a manual script in production did I resort to the md5sum edit.