Dear all,
we are in the process of performing a rather large Update from 7.6 to 7.13 on MSSQL.
During this process I have noticed that the patch-files for 7.8.0->7.8.1 and 7.7.5 to 7.7.6 are the same. Both resolve CAM-8485 and create an index on ACT_HI_PROCINST, which results in a conflict.
My understanding was, that an Update involves applying any patch-sql and any upgrade-sql. I.e. 7.6 => 7.7 as well as 7.6.0 => 7.6.1 and so on.
To be clear, in the update-notes (e.g. Update from 7.9 to 7.10 | docs.camunda.org) it is said to apply patches of the old version first, that is, during update from 7.7 to 7.8 we should first apply all patches of 7.7 (thus creating the index) and then performing the update 7.7 to 7.8. With the next update, we should apply all patches of 7.8 which then would result in the conflict.
Is my understanding wrong? Is there a bug in the sql-update-scripts for MSSQL?
Hi Ingo,
thank you for your answer.
So my summary here is: The update process actually is broken.
As a suggestion: It would be easier for admins, if the relevant scripts where somehow linked in the release-notes.
Maybe the process could be repaired, if such indices would be deleted by the major-update-steps? Say, create in patch 7.9.1, delete in 7.9 => 7.10, recreate in 7.10.3?
Kind regards,
Jonathan
Most of the times the the patch scripts do contain indexes, however, this is not the case all the time. In certain scenarios, such steps (applying/removing) should be avoided.
In addition, I don’t think that is a good idea to create/drop index in certain setup where the database table might contain millions of entries (we’ve seen such environments). And then again some patch scripts are backported 3-4 versions, meaning 3-4 create/drop back and forth.
Also please note that sometimes the patch script is required only for a certain database or setup. This is documented in the table here: Patch Level Update | docs.camunda.org
I agree that applying the updates of the database schema might be a tedious task when trying to update between a couple of minor releases. An update of application/software where database schema update is required can be tricky to select only the necessary updates for a specific setup. And certain applications take care of it to a different degree - without user involvement or with some involvement. So far we don’t provide an automated process to achieve the db upgrade.
We always appreciate feedback in case the process or the documentation is not clear or can be improved.