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

Frequently when you're developing a new application or adding new features, you have to modify your db schema for requirements or bugs. For a new app, I've resorted to a manually executed script to drop all tables and delete everything from the DATABASECHANGELOG table (and the LOCK table for good measure). You can unwind a single change by deleting its record from the change log table and unwinding its change with an anti-query: delete added tables, modify tables/columns back, etc. If I had used runOnChange from the start, this would have cut my migrations.xml file by 50% and saved much time. — Patrick M, Oct 28 '15 at 20:52

score 39 · Accepted Answer · edited Oct 07 '15 at 14:02

39

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.

edited Oct 07 '15 at 14:02

sschober

2,003
3
24
38

answered Jul 19 '09 at 02:53

ChssPly76

99,456
24
206
195

1

that's clear now, i didn't found and read that page in the manual :) – apelliciari Jul 19 '09 at 12:22
4

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. – Shaun Mar 05 '13 at 02:51
Thanks! this is the accurate answer – Biggy_java Feb 04 '14 at 17:41

score 27 · Answer 2 · answered Nov 07 '11 at 17:57

27

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

answered Nov 07 '11 at 17:57

Javid Jamae

8,741
4
47
62

2

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 Mar 05 '13 at 02:50
"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 Aug 04 '14 at 17:11

score 3 · Answer 3 · answered Jul 11 '13 at 22:51

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.

answered Jul 11 '13 at 22:51

rogerdpack

62,887
36
269
388

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. – Patrick M Oct 28 '15 at 20:53

How to work with liquibase, a concrete example

3 Answers3