MidCOM 2.5 Database Upgrades

1. Installation Upgrade
1. Database Update
2. Inclusion of the new Schema Definitions
2. Database Changelog
1. Initial Commit
2. 2005-08-01
3. 2005-08-26
4. 2006-01-23
5. 2006-02-06

This is a MidCOM 2.5 Development Technical Note. Everything written here is subject to change without notice.

With the move to MgdSchema for MidCOM 2.6, there is now the possibility to introduce new core tables / classes into the system. These days I have started to utilize this possibility for both ease of use and performance. To make this work, you need to observe a few things since the MgdSchema core is not fully stabilized yet.

Installation Upgrade

Two steps need to be done here: The database update and the inclusion of the new schema definitions:

Database Update

The distribution now includes an SQL script that can be found at /lib/midcom/config/mgdschema/sql/midcom_dbobjects_full.sql. You need to execute that file for each database you are using MidCOM CVS Head as of 2005-07-15 with. At this time, this script will create a single table, but more may be added at a later time. As long as you follow MidCOM CVS closely, you need to watch that file for changes and updates and integrate them manually.

Inclusion of the new Schema Definitions

MidCOM now ships with a MgdSchema object definition XML file that can be found at /lib/midcom/config/mgdschema/midcom_dbobjects.xml. The following procedure is suggested:

• In the Midgard Share directory (usually $installation_prefix/share/) where the file MgdObjects.xml is located, create a subdirectory schema.
• Create an empty standard schema file merged.xml there (check MgdObjects.xml).
• For each schema you wish to add (f.x. for OpenPSA or MidCOM) you need to add a line like <include name="/path/to/midcom_dbobjects.xml" /> to that file.
• Add a line like MidgardSchema "/usr/local/share/midgard/schema/merged.xml" to your Apache Midgard configuration.
• Restart Apache

I do not know as of this time, if multiple MidgardSchema lines in the VHost configuration are possible now. There were several changes in behavoir and some bugs regarding all this, but the above procedure is confirmed working with CVS branch-1_7 head revisions as of around 2005-09-15.

Database Changelog

This chapter outlines the changes that have been done to the DB structure chronologically. Use it to track changes you need to do to your own database.

Initial Commit

• Included the midcom_core_group_virtual_db object stored in the table midcom_group_virtual. It is used to store virtual group definitions.

2005-08-01

• Included the midcom_core_privilege_db object stored in the table midcom_core_privilege. It is used to store ACL privilege definitions, which will thus no longer be available as parameters.

• Included the midcom_core_login_session_db object stored in the table midcom_core_login_session. It is used to store all currently active login sessions in the system, thus removing it from the person parameters currently used for it.

2005-08-26

• The field client_ip of the table midcom_core_login_session_db has been renamed to clientip due to gobject limitations.

2006-01-23

• Added the table midcom_core_temporary_object_db used in the MidCOM temporary object service.

2006-02-06

• Added tables related to the component midcom.services.at. It has its own schema and sql files in its component directory. See there for further details.