Database Installation / Updating

The DB Updater has to track which files were already installed. We will create a table dbversion and track installed SQL files, with file name, md5 file hash, date, current app version and the app version this file was build for.

If the md5 hash of a already imported file has changed, the dbupdater throws a warning but tries to proceed normally. A md5 hash change should only happen while developing and would be bad coding practice (that happens if a developer changes an already imported sql file).

The script should be callable from shell for developing, and in server context for updating installations.

For developing the directories to be scanned are configured in the starting script.

For updating installations the script looks for the latest Major Version directory in the “APP_ROOT/database” directory. The directory to be crawled for SQL files should be configurable in the ini. So we can use the build_target database dir on productive systems, and all separate source SQL dirs on develop systems. Test systems should be configured like productive systems.

In each source folder can exist an databasemeta.xml file. Actually this file can only contain optional informations about dependencies.

The DB Updater must recognize partition enabled systems, and then install the right SQL files (if there is a difference! Reason: In the future it is planned, to support MySQL table partitioning for the segment- and segment-history tables to still have a good performance with very large amounts of data (> 2 million segments in the DB).