Show Advanced KnowledgeHide Advanced Knowledge

Split DB-Update

This page is only here for documentation, the content is outdated and the general idea is followed up within the (Project) CLI-Setup.

1 Intent

Currently the Jour Fixe decided that new features should be implemented in feature branches and only be integrated in the trunk when the feature was accepted by the sponsor. To be accepted, the new feature gets merged in an 'edge'-branch used for testing an acceptance. The monolithic structure of the db-update-script requires special caution when merging the feature in the edge-branch as well as in the trunk.

Therefore we propose to make it possible that the db-update-mechanism can deal with one db-update-script per module and service.

The splitting of the db-update-scripts would also accomodate the intelligibility of single services and modules, as it bundles the code with the corresponding db-constructions. It would also fit the model of component ownership by module maintainers better than the current shared db-update-script. For future development it could contribute to a cleaner modularization and thus maintainability of the ILIAS-core.

2 Requirements

The ILIAS db-update-mechanism must search through every Module- or Service-subdirectory for a PHP-file called "dbupdate.php", as well as it must take the db-update-scripts in setup/sql/ (refered to as global db-update-scripts below) into account as it does currently.

The module-wise db-update-scripts must be structured according to the current structure of the update scripts, where the enumeration is done per-script.

The db-update-mechanism executes the module- and service-scrips first in alphabetic order of their appearance. It then executes the global db-update-scripts as it does currently.

The db-update-mechanism must provide a functionality for the db-update-script that makes it possible to define lower bounds on the steps performed for another module or service or the global db-update-script. It must be possible to state that a db-update-step requires another module or service or the global db-update having performed a minimum update step. In that case, the order of execution defined above is suspended until the required step is performed.

As a Guideline to the ILIAS-developers, the following is suggested:

• If a db-update-step only modifies or queries the tables of a single service or module it must go into the db-update-script of the service or module. db-update-scripts in a single service or module must not depend on the db-structure of other services or modules.
• If a db-update-step modifies or queries tables from different services or modules it must go into the global db-update-scripts.
• A global db-update-step can require lower bounds on the update-steps of other services or modules.

It is not required to transfer the current db-update steps to component-wise update steps.

3 Additional Information

• Idea / concept: Richard Klees
• Interest in funding: (please indicate if you are interested/able to fund this feature)
• Maintainer: (will be set by Jour Fixe / maintainer)
• Implementation of the feature is done by (will be set by Jour Fixe / maintainer)
• Testcases by: (please add your name if you want to create the testcases for this feature)

4 Discussion

Alex Killing, 31 Mar 2015: In general this would solve lots of issues. We discussed this topic some JF ago and one open issue have been complex migration steps that are related to multiple components. Is there any way of making it possible that a migration step of A requires a certain DB scheme of component B?

Btw. the modularization of language files is a similar issue (of course there are major differences as well). Here the main open question is to keep translation processes easy.

Heyser, Björn [bheyser] I have an additional idea for a change in the dbupdate construct:

Think about the control structure, a re-read is not performed during an update step, but it is registered for later run. This has the advantage that several update steps registering such a re-read does not lead to multiple re-reads, but a single one after the last available update step is performed.

We could extend this construct to have a opportunity for registering custom migration code. When there is a need for using ILIAS core code within the db updates (e.g. a migration that duplicates questions, it is nearly impossible to transfer all this code in custom DBUpdate classes and it is also nearly impossible to rewrite all required db queries) the construct of registering code for later run would have the following advantage.
This code would be executed when the current code base and the current db schema fits to each other.

This migrations still can lead to some issues, therefore this migration registrations should be discussed and accepted by the JourFixe.

5 Implementation

...