LiquiBase Migration 2.0.5 to 3.2.2 runOnChange not executed

General Discussion
1

We are seeing the same situation.  Here is our situation, we have a stored procedure that is loaded in it’s own changeset.  This stored procedure has been around for awhile now.  Recently, it has changed and is ready to be released.  Along with this change we were trying to migrate from 2.0.5 to 3.2.2.  The behavior we saw is the same as mentioned above.  We see the checksum being updated, but the changeset is not being executed.  Even though, the stored procedure has changed.  It’s almost as if liquibase is blankedly changing the checksum and not validating that the changeset has changed.  Is there a migration path we should follow?  Meaning we should migrate to 3.0.1, then to 3.1.0, then to 3.2.2?   

Here is some information we were able to obtain.  It’s not much, but it is all we found at the moment. 

MD5SUM from 2.0.5:

3:076966900dcf8b4ff10930d4307aef1e

MD5SUM after 3.2.2 Upgrade:

7:51fd8131bc28f437fa60a0ca5e9fda45

What comes out in log files:

2014-08-18 16:57:53,964 DEBUG [liquibase] [main]: Computed checksum for 7:4fdb820696b1ca7c77783fbea3139fe3: as 51fd8131bc28f437fa60a0ca5e9fda45

2014-08-18 16:57:53,964 DEBUG [liquibase] [main]: Executing EXECUTE database command: UPDATE LIQUIBASE_{db user} SET MD5SUM = ‘7:51fd8131bc28f437fa60a0ca5e9fda45’ WHERE ID=‘{changeset-id}’ AND AUTHOR=‘{author}’ AND FILENAME=‘{filename}’

…

…

2014-08-18 16:57:56,174 DEBUG [liquibase] [main]: {filename}: {parent filename}::{changeset id}::{author}: Computed checksum for inputStream as 4fdb820696b1ca7c77783fbea3139fe3

 

2

Hi,

This morning I just realized that the runOnChange it is not working as should be. 

We were checking this page http://www.liquibase.org/v3_upgrade.html and we saw that there are problems form 2.x version to the 3.x. But it is not clear at all what is the problem and what we should do.

What we see is that the EXECTTYPE is RERAN, and the checksum was the correct one, but we don’t have the changes in the database. Also the DATAEEXECUTED is a date in the past.

I fix it deleting that entry from databasechangelog and run it again, and then i get the changes EXECTYPE EXECUTED, and all correct.

It is this a good solution ? do you guys have a better idea ? are you aware of that problem ?

Thanks in advance,

3

Yes, the trouble is that while I try to avoid changes to the checksum logic, sometimes it is not preventable. When there is a change in the logic, that means we cannot know if a changeSet has changed or not and so what should be done with a runOnChange=“true” changeSet? Do you run it or do you not? 

You can make an argument either way but the way that was chosen was to assume they did not change and therefore not run them and just update the checksum with the new logic. 

If you have changeSets that you know changed and so you want to be ran when you are upgrading from 2 to 3, the easiest solution is probably to change the ID, that way it is seen as a new changeSet and is re-ran regardless. 

Nathan