Liquibase migration from Camunda, already on version 7.24.0

Development
1

Hello,

Mention: using Operaton 2.2.0-M2

As steps of how I overcame the problem mentioned in the link / came to a resolution.

I have a added before-camunda.xml.

What does this include?

DELETE FROM DATABASECHANGELOG
WHERE ID = '7.24.0-tag'
  AND AUTHOR = 'Camunda'
  AND FILENAME = 'org/camunda/bpm/engine/db/liquibase/camunda-changelog.xml'
  AND EXISTS (
    SELECT 1
    FROM DATABASECHANGELOG
    WHERE ID = '7.24.0-tag'
      AND AUTHOR = 'Operaton'
      AND FILENAME = 'org/camunda/bpm/engine/db/liquibase/camunda-changelog.xml'
);

and

UPDATE DATABASECHANGELOG
SET AUTHOR = 'Operaton',
    MD5SUM = NULL
WHERE AUTHOR = 'Camunda'
  AND ID IN ('7.23-to-7.24', '7.24.0-tag')
  AND FILENAME = 'org/camunda/bpm/engine/db/liquibase/camunda-changelog.xml';

Reason?

Liquibase identifies changesets by ID + AUTHOR + FILENAME. When upgrading from Camunda to Operaton, the AUTHOR changed from ‘Camunda’ to ‘Operaton’, so Liquibase sees it as a new changeset and tries to re-execute it.

Solution

DELETE — Remove the old Camunda tag if the new Operaton tag already exists (cleanup for failed/retried deployments)
UPDATE — Change the AUTHOR from ‘Camunda’ to ‘Operaton’ for the two known changesets, plus clear the MD5SUM so Liquibase doesn’t complain about checksum mismatchesFor fresh databases: These statements do nothing (0 rows affected), and Operaton just creates everything normally.

I went for a solid idempotent migration pattern — smart defensive coding for the version transition.

To be noted: I was at Camunda version 7.24.0 before integrating Operaton.

Hope this helps, if you need any other information, let me know.
Much appreciated. Enjoy your week!

1 Like
Operaton 2.1.4 and 2.2.0-M3 released