i have a question regarding the database changelog scripts. Here’s the scenario with the following sample application:
In the VCS we have a trunk based version and a 1.0.x branch.
Both contain 10.create-db.sql which will create a table customer (with a name attribute, length 255, not mandatory).
- on 2017-03-01 there is a 1.0.0 release and the branch 1.0.x gets created
- on 2017-03-02 there is a change in trunk which will increase the size of the name column to 4000
- on 2017-03-03 there is a change in 1.0.x which will define the name column as mandatory
- on 2017-03-04 there is a 1.0.1 release with the changes in branch but not in trunk
1.0.0 and 1.0.1 are now in production.
So here is the question:
On 2017-03-10 there will be a 1.1.0 release which should contain the changes from 1.0.x and the change (2.) from trunk.
How will the database migration tool react if the filename of the change from 3. is “170303-2-updateCustomerNameMandatory.sql” and the trunk filename of change (2.) is “170302-2-updateCustomerNameLength4000.sql”
Normally from the sort by name, so it would execute the trunk file (2.) first and the branch file (3.) after that, correct? Although in my examples the changes don’t depend on each other, it could be possible that this is. In this case, what would you do?
I can think of the following approaches:
Option 1: rename the “170303-2-updateCustomerNameMandatory.sql” (3.) to a date that is before the change in the trunk and then copy it over to trunk. This would enable the SYS_DB_CHANGELOG table to see have the file from branch and after switching to trunk it would just append the trunk files (3.). But does that mean, that every change in the branch has to be executed before the first trunk change? What are potential downsides on that?
Option 2: leave the name as it is and merge it over to trunk. In trunk there will be the following files after that:
# ~/dev/projects/examples/cuba-question-changelog-with-branch/modules/core/db/update on git:master ?? [13:18:37] ? tree . ??? hsql ??? 17 ??? 170302-2-updateCustomerNameLength4000.sql ??? 170303-2-updateCustomerNameMandatory.sql 2 directories, 2 files
Then in the SYS_DB_CHANGELOG there will be already a entry for the “170303-2-updateCustomerNameMandatory.sql” (3.) that will not get executed anymore. In this case, i’m not sure if it is just enough to do so and then the DbUpdater will pick up the trunk file (2.) and execute it. Im not really sure how this will look like. Is the sorting of the filename irrelevant in this case?
Im just trying to get my head around this stuff and perhaps this has nothing to do with CUBA but more with the possibility to use branches correctly and how to deal with these db changes in this cases.
Nevertheless, i would really be interested in how you do handle this kinds of situations and what would be the right decision if the trunk change has some expectations on the state of the db that the branch change will invalidate. Or would we just simply adjust the trunk db change (which should normally never be done on a changelog script), because it has never been released?