Changing a property value doesn't rerun a changeSet

General Discussion
1

It seems that if I define a stored procedure with an embedded property value, then it doesn’t rerun the changeSet when the property value changes. Is this expected behavior?

2

We had a similar case, and have added the property to the changeset Id to achieve what we wanted. This way the Id is new if the property value is changed, and the changeset is rerun.

Something like this:

	<changeSet author="..." id="...-${propertyName}">
             <....>
	</changeSet>
3

Do you have runOnChange set to “true”?

4

This could point to an issue in the checksum logic. Out of curiosity, do you have an example changeset where you are seeing the problem that you could share?

5

Yes, that would cover where the property value was changed to be a new value as an additional changeSet entry would be created in the database changeLog. However, if the property value was later changed back to its original value, then the changeSet would not be rerun based on what I have seen when using the tag.

6

Our case is not identical then, as in our case it should never re-execute if the property value is changed back to its original value. That would actually fail.

Does it still not work for you, even if you set runonchange=true?

7

I have created a test that shows the issue (using a SQL Server database).

<?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">

  <property name="property1" value="value1" global="true"/>

  <changeSet author="x" id="1" runOnChange="true">
    <sql>
      drop synonym if exists synonym1;
      CREATE SYNONYM synonym1 FOR [${property1}].[dbo].[TEST1]
    </sql>
    <rollback>
    </rollback>
  </changeSet>

  <changeSet author="x" id="2" runOnChange="true">
    <sql>
      drop synonym if exists synonym2;
    </sql>
    <sqlFile
      path="synonym2.sql"/>
    <rollback>
    </rollback>
  </changeSet>

</databaseChangeLog>

synonym2.sql

CREATE SYNONYM synonym2 FOR [${property1}].[dbo].[TEST2];

First deployment;

Starting Liquibase at 10:11:19 (version 4.9.1 #1978 built at 2022-03-28 19:39+0000)
Liquibase Version: 4.9.1
Liquibase Community 4.9.1 by Liquibase
[2023-04-12 10:11:21] INFO [liquibase.database] Set default schema name to dbo
[2023-04-12 10:11:22] INFO [liquibase.lockservice] Successfully acquired change log lock
[2023-04-12 10:11:23] INFO [liquibase.changelog] Creating database history table with name: DATABASECHANGELOG
[2023-04-12 10:11:23] INFO [liquibase.changelog] Reading from DATABASECHANGELOG
Running Changeset: test.xml::1::x
[2023-04-12 10:11:24] INFO [liquibase.changelog] Custom SQL executed
[2023-04-12 10:11:24] INFO [liquibase.changelog] ChangeSet test.xml::1::x ran successfully in 79ms
Running Changeset: test.xml::2::x
[2023-04-12 10:11:24] INFO [liquibase.changelog] Custom SQL executed
[2023-04-12 10:11:24] INFO [liquibase.changelog] SQL in file synonym2.sql executed
[2023-04-12 10:11:24] INFO [liquibase.changelog] ChangeSet test.xml::2::x ran successfully in 85ms
[2023-04-12 10:11:24] INFO [liquibase.lockservice] Successfully released change log lock
Liquibase command 'update' was executed successfully.

Second deployment after updating the property values to “value2”;

Starting Liquibase at 10:13:27 (version 4.9.1 #1978 built at 2022-03-28 19:39+0000)
Liquibase Version: 4.9.1
Liquibase Community 4.9.1 by Liquibase
[2023-04-12 10:13:28] INFO [liquibase.database] Set default schema name to dbo
[2023-04-12 10:13:29] INFO [liquibase.lockservice] Successfully acquired change log lock
[2023-04-12 10:13:32] INFO [liquibase.changelog] Reading from DATABASECHANGELOG
Running Changeset: test.xml::1::x
[2023-04-12 10:13:33] INFO [liquibase.changelog] Custom SQL executed
[2023-04-12 10:13:33] INFO [liquibase.changelog] ChangeSet test.xml::1::x ran successfully in 278ms
[2023-04-12 10:13:35] INFO [liquibase.lockservice] Successfully released change log lock
Liquibase command 'update' was executed successfully.

In the second run, the second changeSet did not get rerun. Interestingly, the behavior works as expected for the <sql> tag, but not for <sqlFile>. In this example, I could workaround the issue by placing the synonym definition within the changeSet, but the real world scenario is where there are property values embedded in stored procedure code, so the preference is to use a separate SQL script for each stored procedure and reference the script in the changeSet.

Same behavior seen in Liquibase 4.20.0.

8

Yes, I think that our scenario is different. In our case, we use using properties to manage the differences in link server and database names that are embedded within various database objects (mainly stored procedures), where we are also using contexts to manage environment differences. Within our development environments things get changed from time to time, so we expect any update in a property value to trigger a rerun of a changeSet where it has been defined with runOnChange=true.

9

This appears to be a bug where the only current workaround I think can be used is to set the affected changeSets to runAlways=“true”. This is not ideal as we would really want to define them as runOnChange=“true” and then for Liquibase to correctly detect the change which includes any change in property substitution.