Upgrading¶

The monitoring extension uses Hibernate to persist request data. Changes to the extension over time affect the structure of the underlying database, which should be taken into consideration before performing an upgrade. Depending on the nature of changes in an upgrade, it may involve manually making changes to the underlying database before deploying a new version of the extension.

The sections below provides a history of such changes, and recommended actions that should be taken as part of the upgrade. Upgrades are grouped into two categories:

• minor upgrades that occur during a minor GeoServer version change, for example going from 2.1.2 to 2.1.3. These changes are backward compatible in that no action is specifically required but potentially recommended. In these cases performing an upgrade without any action still result in the monitoring extension continuing to function.
• major upgrades that occur during a major GeoServer version change, for example going from 2.1.2 to 2.2.0. These changes may be backward compatible, but not necessarily. In these cases performing an upgrade without any action could potentially result in the monitoring extension ceasing to function, and may result in significant changes to the underlying database.

For each change the following information is maintained:

• The released version containing the change
• The date of the change
• The subversion revision of the change
• The jira issue referring to the change

The date and subversion revision are especially useful if a nightly build of the extension is being used.

ALTER TABLE request_resources RENAME COLUMN resource to name;

UPDATE TABLE request_resources SET name = resource where name is NULL;
ALTER TABLE request_resources DROP COLUMN resource;

ALTER TABLE request ADD COLUMN remote_user_agent VARCHAR(1024);