We are working on an application that is subdivided into several licensable sub-applications.
There is one central base application, that contains some metadata on all the sub-applications. Apart from that sub-applications are not allowed to refer any other sub-application but BASE.
Up until now we had a separate directory structure for each sub: BASE/install & BASE/update for the BASE app, FIN/install & FIN/update for the FIN sub, etc.
Working in dev and propagating changes to test when changes occurred went fine: we would run the updates from BASE, followed by the other subs.
However, when doing a fresh install after some time, we ran into the following:
01/01/2010: in FIN a table is added. Info about that table is inserted into BASE.TABLES
01/03/2010: in BASE.TABLES a column ind_backup was added. An sql is provided as part of this script that updates existing rows. Finally the column is made mandatory
01/04/2010: in FIN a table is added. Info about that table is inserted into BASE.TABLES, including a value for the new (mandatory) column
This scenario works out ok when run in this order (as we do on dev & test). However, when run as a fresh install, the order will be:
- First run all BASE scripts
- then run all other scripts (per sub-app)
So, this means that the mandatory column is created before the first insert on BASE.TABLES takes place.
The 01/01/2010 insert in turn fails, because at that time the mandatory column did not exist.
So, my questions are:
Is this a familiar scenario?
Is there a smart solution for this that we are overlooking?
Should we go into a single LB structure and explicitly define the schema in every changeset?
Thanks in advance for looking into this,