This document describes some of the metadata used by the DLXS middleware. The dlxs database contains metadata about the collections and the collection groups.
Contents:
The Collection Manager (collmgr program) maintains all collection and group information in tables. These tables are the following:
| No | Table | Description |
| 1 | Collection | This table contains all the collection parameters common to all the classes. In some cases, a particular parameter may not currently be used by a class, but may be in future releases. |
| 3 | BibClass | This table contains all the collection parameters that are specific to a bib class collection. |
| 5 | TextClass | This table contains all the collection parameters that are specific to a text class collection. |
| 7 | ImageClass | This table contains all the collection parameters that are specific to an image class collection. |
| 9 | GroupData | This table contains all the group parameters that are common to all the classes. In some cases, the parameter is not currently being used by a class, but may be in future releases. |
| 11 | BibClassGroup | This table contains all the group parameters that are specific to bib class. |
| 13 | TextClassGroup | This table contains all the group parameters that are specific to text class. |
| 15 | ImageClassGroup | This table contains all the group parameters that are specific to image class collections. |
| 17 | GroupColl | This table contains the relationship between groups and collections. It tells which collections are in which groups. |
| 19 | CheckinCollection | This table is used to maintain a record of which user checked in which collection and at what time. |
| 20 | CheckoutCollection | This table is used to maintain a record of which user checked out which collection and at what time. |
| 21 | CheckinGroup | This table is used to maintain a record of which user checked in which group and at what time. |
| 22 | CheckoutGroup | This table is used to maintain a record of which user checked out which group and at what time. |
| 24 | Version | This table maintains the version number of the database. |
These tables serve to identify and locate the various modules, objects, and search restrictions that are used by the class middleware to serve each collection available in the various classes. See more on the tables in the database in the collmgr documentation.
Some of the columns contain data that are required; others contain optional data. Multiple values, which are allowed in some fields, are entered through collmgr, into the appropriate fields one value per line.
All but Version table have a field called userid. userid can take on several values with very specific meaning. One is that of the dlxsadm. The other important value is production. Finally, another value might be that of a specific developer logged into collmgr, say smith. These are explained here.
The userid dlxsadm is referred to as the release user. The middleware will read rows keyed by userid dlxsadmn from these tables when the following are true:
The userid production is referred to as the production user. The middleware will read rows keyed by userid production from these tables when:
The userid smith, for example, is referred to as the development user. The middleware will read rows keyed by this userid when:
This will allow smith to perform testing based on collections and groups of his choice that he can set up using the Collection Manager. Most institutions will not need to use this third type of user because there will not be a need to have several users work against the same collections. For those institutions, it will only be necessary to log in to the Collection Managmer as dlxsadm. All data management can happen through that userid.
In addition to being able to delete, add, or edit collections and groups associated with the dlxsadm user, this administrative login userid has other privileges. The dlxsadm will be able to add fields to classes, and delete fields from classes. This will change the structure of the tables associated with the classes.
Note that when the userid dlxsadm deletes a collection or group, a backup of the deleted collection or group is kept in the appropriate backup tables.
The user dlxsadm also has privileges to release classes to production. "Releasing to production" effectively copies every dlxsadm row to a row keyed by the userid production. This distinction between dlxsadm and production, allows you to work on collections and groups independent of the collections and groups that are accessible by the version of the middleware that is running in production.
For information on the individual fields, please see the help file used by the Collection Manager (collmgr).
Most users of DLXS Middleware will likely have the following situation. A collection manager will be making changes to the collection information database, changing, adding or deleting collections. Then at some point, the new set of collections to be delivered will need to go into production. The database holds both sets of rows.
The middleware can be set to look at either the release rows (for testing and subsequent release) or the production rows (rows actually being used by the production system). This is accomplished through the setting of the environment variable DLPS_DEV. If set to 1, the release rows and their values are used by the middleware. If set to 0 or not present, the production rows are used by the middleware.
Therefore, two environments need to be set up: one for release and one for production. These can be set up as separate virtual hosts on a web server, each defining its own environment variables, or as servers on two separate machines. At DLPS, we have a separate development machine and more than one production machine, but it seems to be the case that most DLXS partners have one machine where both development and production are done.
In either case, the situation is that there are two sets of rows in the database and two servers (whether they are virtual hosts or actual separate physical hosts is irrelevant). (In addition there is an extension to this scheme whereby each individual developer can have his/her own set of rows in order to develop without disturbing the database values in the release and production rows.)
For example, assume there is one machine with two virtual hosts (dev.domain.edu and prod.domain.edu). The configuration for the virtual host dev.domain.edu should have a SetEnv directive setting DLPS_DEV to 1. The configuration for the prod.domain.edu virtual host should not include this environment variable setting.
When the dev.domain.edu server is asked to run the middleware it will access the release rows in the database and use their values.
Note: As mentioned, if you want to run the cgi programs on the command line or within a debugger, you'll need to set your own shell environment to include a DLPS_DEV variable set to 1.
Likewise, the production rows and their values will be used for any cgi call to the prod.domain.edu virtual host because the user that the web server runs as (e.g., nobody) will not have the DLPS_DEV environment variable set. This is because no SetEnv directive in the prod.domain.edu's virtual host configuration will have been set.
When running the Collection Manager cgi, you should log in as user dlxsadm in order to add, remove, edit rows that are the release rows. When you want the working production system to actually use your changes, the Collection Manager lets you "move release rows to production", which actually copies the rows keyed by the user dlxsadm to rows keyed by the user production. You cannot directly manipulate the production rows. This layer of protection is something akin to "checking in" data. Click here for more on the collmgr workflow.
| to use | collmgr |
| release rows | log in as dlxsadm, view and edit rows |
| production rows | log in a s dlxsadm, view rows, copy release rows onto production rows |
If you do work where different users require individualized versions of the database rows, as we do at DLPS, the databases can also be set up with, in addition to the release and production rows described above, rows keyed by username. In addition to the material below, please refer also to the instructions related to configuring this username extension.
Here, there are at least three sets of rows: the same two as before, but with additional sets for individual developers. A user can:
The middleware can be set to use the release rows or the user name rows. This is accomplished by:
The middleware can also be set to use the user specific rows. This is generally done to test new functionality in the middleware or to try out potential changes to the database field values. This is accomplished by:
When running the Collection Manager cgi, in order to make changes to the rows keyed by your user name, you should log in as username. This allows you to check out rows from the release rows, view and edit your own rows, and check them back in to release. Click here for more on the Collection Manager workflow.
| to use | collmgr |
| release rows | log in as dlxsadm, view and edit rows |
| production rows | log in as dlxsadm, view rows, copy release rows onto production rows |
| username rows | log in as user, checkout release rows, view, edit user rows, checkin rows to release |
Imagine your username is smith. When you log in to the Collection Manager cgi, you can check out rows from the release rows (they are copied) to rows that are keyed by the userid smith. You can make changes to these rows so that when you access them through the middleware (running under a virtual host with DLPS_DEV set to smith and DLXSROOT set to smith's copy of the code tree under development), the values from those rows will be used. If or when you check them back in, the values you entered/changed in the smith-keyed rows will be copied into the corresponding release rows.
Later, when ready, logging in as dlxsadm, one can "move" release to production.