Rolling DB Updates: 7.22 -> 7.23

I’m trying to get the rolling DB update tests to work and am confused a bit.

After fixing some version issues the module qa/test-db-rolling-update/create-new-engine is now trying to set up a database and execute statements in the build.

I’m getting this error:

Caused by: org.h2.jdbc.JdbcSQLSyntaxErrorException: Doppelter Feldname "REV_"
Duplicate column name "REV_"; SQL statement:
 
 alter table ACT_HI_COMMENT
 add column REV_ integer not null

The error occurs when executing the upgrade from 7.22 to 7.23 by h2_engine_7.22_to_7.23.sql:

alter table ACT_HI_COMMENT
    add column REV_ integer not null
        default 1;

This column is added with creation of the ACT_HI_COMMENT table in activiti.h2.create.history.sql:

create table ACT_HI_COMMENT (
   ...
    REV_ integer not null default 1,
   ...
);

So I think the error is OK. My confusion is: Why is there actually this change at all? It has been backported from PR#4565.

From what I would say this upgrade is not correct, i.e. the alter table statement has to be deleted.

Could someone provide an opinion on this?

Hello @kthoms,

thank you for your work and the hint on this issue.

When i look in the original PR they added this column for the create table and alter table statement in the same change.

And now you should think about set up a new database or running the update on an existing database.

For this i think you have to set up an older version of the database where the REV_ column is not part of the create table statement. So the update is doing the job.

When you set up a database of the same version you will get your issue.

I hope this help. When you want to talk about ping me.

1 Like

I think this is because we have not merged this commit yet:

So camunda.version.old is set to 7.22

But we are creating a schema that is partly 7.23

We need to merge this feat(core): expose process def key in process instance API (#4847) by hauptmedia · Pull Request #710 · operaton/operaton · GitHub and then backport chore(release): prepare codebase for 7.24 development (#5071) · camunda/camunda-bpm-platform@6947262 · GitHub

Ah, I thought we had already the changes for 7.23 in place and wanted to enable the tests before actually merging your backport. I was distracted because it was mentioned in the PR that something has to be executed manually against the database.

We have “deployed” an incomplete version of the 7.23 scripts then. This means, with Beta-5 I would change the version to 7.23.1.

I will follow the pointers from both of you.

I would strongly recommend not changing the version to 7.23.1, as this could easily be mistaken for a patch release of the Camunda EE 7.23 version. To avoid confusion, we should keep the database version aligned with the official C7 CE releases until its EOL.

Instead, my suggestion is to simply append the missing migration step to the existing 7.23 scripts and keep the version as 7.23. This will, of course, break any currently running beta-4 instances upon upgrade to beta-5, since the new column will be missing. A manual intervention is needed in those cases to add the column manually.

The only point that still needs attention is how we handle this for H2 - for other databases, it should be straightforward.

Since we’re still in beta, I think this approach is acceptable, as long as we clearly document it in the release notes and migration guide.

1 Like

I would also propose to imitate all script versioning as it is from Camunda, to avoid any surprises when later doing the migration from Camunda to Operaton. Liquibase can be quite sensitive about differences, and I’d be more content with breaking something “Operaton → Operaton” in Beta than breaking something from “Camunda → Operaton” forever, so I completely agree with Julian here

1 Like

Yes, it was a good decision that we stick with the versioning scheme for the database with Camunda. It is important to separate between the version of Operaton (1.x) and its database scheme (currently 7.23).

I had already to adjust something in the rolling-db-update modules regarding to that and I am currently at the point that scripts are executing. But I got stuck rsp. confused by the problem mentioned above. Now with your help I see a bit clearer again.

Short update: It was causing major headaches because I did not realize how the “old engine” database was created and which is the correct mixture of database scheme versions and Operaton version.

Actually, the DB scripts for Camunda 7.22 were included in Operaton 1.0.0-beta-2. With beta-3 the db creation scripts were already on an early 7.23.

I have finally managed to get a build for qa/test-db-rolling-update running.

I will now provide the integration into the CI build and then provide a PR.

00:54:57,216 [INFO] Reactor Summary for Operaton - QA - upgrade - rolling update 1.0.0-beta-5-SNAPSHOT:
00:54:57,216 [INFO] 
00:54:57,216 [INFO] Operaton - QA - upgrade - rolling update ........... SUCCESS [  0.184 s]
00:54:57,216 [INFO] Operaton - QA - upgrade - rolling update util ...... SUCCESS [  1.340 s]
00:54:57,216 [INFO] Operaton - QA - upgrade - rolling update - create old engine SUCCESS [  2.377 s]
00:54:57,216 [INFO] Operaton - QA - upgrade - rolling update - create new engine SUCCESS [  3.408 s]
00:54:57,216 [INFO] Operaton - QA - upgrade - rolling update - test old engine SUCCESS [  1.190 s]
00:54:57,216 [INFO] ------------------------------------------------------------------------
00:54:57,216 [INFO] BUILD SUCCESS
00:54:57,216 [INFO] ------------------------------------------------------------------------
00:54:57,216 [INFO] Total time:  8.813 s
00:54:57,216 [INFO] Finished at: 2025-06-28T00:54:57+02:00
00:54:57,216 [INFO] ------------------------------------------------------------------------
✅ Database update tests completed successfully
1 Like

fyi after beta-5 release the first backport will be this: chore(release): prepare codebase for 7.24 development (#5071) · camunda/camunda-bpm-platform@6947262 · GitHub

This will increase the db version to it’s final version 7.24

Good to know. I’ll have to think about how we deal with that. Since we will likely release Beta-6 before 7.24 final, and ship intermediate versions of the SQL scripts. Maybe we have to suppress 7.24 releases until it is final, but this could require manual steps for installing Beta-6.