I’m not working with Cuba for a long time now, I’ll like to know from the experts how to deal with some entities changes without touch the database.
Overview
Please, let me to introduce my scenario:
A Cuba Application that holds some common features (entities, screens, etc)
A couple of Cuba Applications that have their own features plus the common features
Every Cuba Application has its own MySQL database
This solution is live and running using the components application model, as described in docs, it works as a charm.
The problem
Live application with live problems, sometimes I’ve to deal with a situation where one of the entities, (including screens, etc) needs to be moved from one application to common or the inverse.
Since we’re talking here about running applications, the database needs to be untouched and I can’t allow any drop scripts to run there, cause the entity will still exist, but from other application (add-on).
Those applications are running inside docker images with cuba.automaticDatabaseUpdate option enable. I wouldn’t like to change it, I think it works well for our needs.
I read the docs many times but never found an explanation about how to deal with that type of situation. What I use to do is insert those scripts in db-changelog table to avoid them to run.
My question is, how do you deal with that? Needs to be a better way to deal with it.
Hi @felipefda,
Database scripts are treated as code, so you can delete them if you want to. Take a look in the docs for additional information.
If I were in your shoes, I would probably rename the objects when doing such refactoring, because of the objects’ names (take a look at components naming rules).
The main thing to keep in mind is that you need to evaluate the impact of the execution of the script from the application point of view. Each new update script in the component project will be executed by every application using it.
If I understood correctly, there are 2 main situations, and for each of them I would recommend the following:
1. Moving objects from an application to the component
In the application project:
Remove the “drop database” script generated automatically by Cuba Studio
Create new scripts to rename the table instead of dropping them (“APP_ENTITY” → “COMP_ENTITY”)
Rename the entity name values (if you use inheritance, maybe you have some columns with references to the entity name - “app_Entity” → “comp_Entity”)
In the component project:
There is nothing to worry about. Just generate the scripts using Cuba Studio.
2. Moving objects from the component to the applications
In the component project:
Remove the “drop database” script generated automatically by Cuba Studio
Create new scripts to rename the table instead of dropping them (“COMP_ENTITY” → “APP_ENTITY” )
Rename the entity name values (if you use inheritance, maybe you have some columns with references to the entity name - “comp_Entity” → “app_Entity”)
In the application project:
Generate the scripts using Cuba Studio.
Remove the “create database” update scripts generated by Cuba Studio
Hi,
In the Database Scripts window there are buttons on the top of the table with new scripts.
You can select the script that you want to be ignored forever and press the “Exclude script” button.
If you click (exclude), you will have two options:
Move the script to the directory of manually executed scripts: modules/core/db/update-manually or modules/core/db/update-manually_{additional_data_store_name} . Then the script will not be executed automatically when you run Update database , but you will be able to run it manually when needed. This option is useful for scripts that drop columns or tables renamed earlier to *__UNUSED .
Exclude the script: it will not be saved to the modules/core/db/update directory, but remembered in the studio-intellij.xml file in your project folder. When you generate scripts next time, Studio will ignore changes, corresponding to the excluded scripts. This allows you to maintain difference between the database and the model entities.
For example, you may want to add a database field to a table, corresponding to a project entity, but do not map it to an entity attribute. When Studio generates a script to delete the field from the database, just exclude it, and Studio will never generate it again.
(exclude), you will have two options: