The DLXS Collection Manager CGI: collmgr

Overview and Contents

This document describes the Collection Manager CGI program (collmgr) delivered with the DLXS middleware. It is used to maintain the metadata databases that allow the DLXS middleware to access information about specific collections and groups of collections implemented through the middleware.

The collection information and groups information databases 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. For more information about the databases themselves, click here.

collmgr is a CGI program whose main function is to manage collection and group information. This CGI program allows you to maintain this information in a MySQL database.

For information on the individual fields, please see the help file used by the Collection Manager (collmgr)

IMPORTANT: To learn about the databases and their structure and for an explanation of how different user IDs affect which rows of data are retrieved from the databases see Interaction between database rows, users, DLXS Middleware and collmgr.

Contents:

Definitions

In the following explanations, certain terms are used that need some explanation.

user ID
The user ID is the key in the database (either collection or groups database) that determines which row of metadata information in the database will be used for a particular collection or group of collections.
release
The term release refers to the database rows that have been released by individual developers for testing by a larger audience. When testing is complete, these are the rows that will be moved into production. These rows in the databases are keyed by the user ID dlxsadm. At DLPS, these are rows that are seen by the middleware when running in the "release" directory, as opposed to a particular developer's work directory, and when the DLPS_DEV environment variable is set to 1.
production
Rows in the databases keyed by this user ID are seen by the middleware in the production environment; that is, when the DLPS_DEV envrionment variable is set to 0 or not defined.
REMOTE_USER
This environment variable is set by an authorization system when running the collmgr. It determines what permissions a user has when managing the databases. For example, if the authorization system allows each user to log in as a unique individual with his or her own user ID (see DLPS development environment), that user may check out rows into their own working environment, or make changes to rows and check them back in. If the user logs in as "dlxsadm", the user may "release" the rows keyed by "dlxsadm" (that is, the "release rows") to production and may also add or delete fields from tables.

Workflow for someone managing a collection with a user ID other than dlxsadm

Managing collections

When you login to manage a collection, you are asked whether you wish to manage collections or groups. Then you are asked to select the class with which you wish to work. A list of working collections will be displayed. These are the collections you have checked out under your user ID.

The first time you run collmgr, this list will be empty. In order to build up the list you can choose to checkout collection. This will display a page where you will be permitted to select one or more collections to checkout. Checking out actually creates a copy of the collection database row keyed as release. The new row is keyed by the user ID of the user requesting the checkout.

Returning to the page that lists your working collections, you will see the collection(s) you have just checked out. You can then view them or edit them as you wish, one at a time.

If at any time you wish to get a more up-to-date version of a collection (see point below regarding aging) from the release pool or to undo some changes you have saved to your copy, just check it out, and the values in your row (i.e., the row for that collection which is keyed by your user ID) will be overwritten with those in the release row.

You can also create a new collection, and then check it in. Checkin places the collection in the release pool (by actually copying the row into a new row with all the same values except for the user ID, now dlxsadm (note: any row with user ID dlxsadm is known as a release row or release collection). If you find that you no longer need a collection in your working list, select remove working collection, and it will be removed from your working list (i.e., the row for that collection which is keyed by your user ID, will be deleted). Note: The release pool is not affected by this function because the release row (keyed by user ID dlxsadm) is not deleted.

Here are some important points to keep in mind when developing collections using collmgr:

Managing Groups

Managing groups works in much the same way as managing collections. You will be able to create a group, check out groups, delete groups from your working list, and then check in your changes.

However, there is one additional layer of complexity that comes with working with groups: the relationship that exists between groups and collections. Note the following:

Workflow for someone managing a collection with user ID dlxsadm

The principal difference when managing collections and groups when logged in as dlxsadm is that you are editing the release rows in the database directly. That is, you do not check out and check in rows. The edits you submit affect the release rows immediately.

If your DLXS site does not involve interactions among many collection developers, each needing their own work space, you may decide that the easiest approach is just to use the single user ID: dlxsadm to accomplish all your collection development.

If you delete a working collection, only the 'release' version is deleted. All user collection rows are kept and also the production collection rows. A release to production at this point will overwrite the production collection row. This differs from the case where, when logged in as an individual user, if you remove a collection, it is only removed from that user's set of working rows, not from release or production. Deleting a group behaves the same as deleting a collection. The collections in the group are not affected, however.

A quick glance at the initial collmgr page will show that when logged in as dlxsadm you are allowed to manipulate the databases in ways that individual users cannot. Following is a list of these additional priviledges.