Database synchronization script drops important data. Why?

1
We are upgrading from 5.9.1 to 5.16.1 and continuing development in 5.16.1. Now it turns out that after the new deployment some data will be missing: All data in attribute 'Telwerknummer' of entity 'Meterstand' All data in association 'Opdrachtregel_Opdracht' This must be caused by the following commands in the generated database script: ALTER TABLE "customintegration$meterstand" DROP COLUMN "telwerknummer"; ALTER TABLE "customintegration$meterstand" ADD "telwerknummer" int4 NULL DEFAULT 0; ALTER TABLE "customintegration$opdrachtregel_opdracht" RENAME TO "03ebbc8e14e94d85a0fad3198f244aec"; DROP TABLE "03ebbc8e14e94d85a0fad3198f244aec"; CREATE TABLE "customintegration$opdrachtregel_opdracht" ( ... ) As far as I know, I never touched (deleted) the attribute or the association in the Modeler. Could anyone think of any other reason why such DROPs may appear in the database script? (I think I am not allowed to publish the domain model, unfortunately.) Thanks for your time.
asked
3 answers
2

Solved by merging a missing revision from another branch. In that revision, yellow entities were turned blue (and probably got the internal ID). Sebastiaan and Thijs, thanks again for your support.

answered
1

A drop like that wouldn't normally happen unless you recreated the attribute or association (so it has a different id internally) or really changed the type in such a way it's impossible to preserve the current data. Do you see the same happening if you take the old 5.9 model and apply that to that database? What if you just convert the model to 5.16 and do it?

answered
0

Had exactly the same problem. Reason was the merging of branches, this genated the drop statements.

We resolved this by backing up the database before the synchronization. We created db scripts that restored the data. To create the scripts, you need to analyse the synchronization script, detect all the drop statements and create a script per drop statement.

answered