升级¶
监视扩展使用Hibernate来保存请求数据。随着时间的推移，对扩展的更改会影响基础数据库的结构，在执行升级之前应该考虑到这一点。根据升级中更改的性质，它可能涉及在部署新版本的扩展之前手动更改基础数据库。
下面的部分提供了此类更改的历史记录，以及作为升级的一部分应采取的建议操作。升级分为两类：
少数的 在GeoServer版本发生微小更改时发生的升级，例如从2.1.2升级到2.1.3。这些更改是向后兼容的，因为不需要特别的操作，但可能是推荐的。在这些情况下，执行升级而不执行任何操作仍会导致监视扩展继续运行。
专业 主要GeoServer版本更改期间发生的升级，例如从2.1.2升级到2.2.0。这些变化 may 向后兼容，但不一定。在这些情况下，在不采取任何操作的情况下执行升级可能会导致监视扩展停止工作，并可能导致对基础数据库的重大更改。
对于每次更改，都会保留以下信息：
包含更改的已发布版本
变更日期
对修改的颠覆
关于变化的JIRA问题
如果使用扩展的夜间构建，则日期和子版本修订尤其有用。
轻微升级¶
柱 resource 重命名为 name 在里面 request_resources 桌子¶
版本 ：n/a，扩展仍为社区状态
Date ：2011年12月9日
颠覆修订 ：16632个
参考文献 ： GEOS-4871
升级而不执行任何操作将导致 name 正在添加到的列 request_resources 桌子，离开 resource 柱子完好无损。从那以后 resource 基本上将忽略列。但是没有来自 resource 列将被迁移，这将抛出报表、资源访问统计信息等。。。如果要迁移数据，请执行以下操作之一两个操作。
第一个是 pre 升级操作，只需在部署新的监视扩展之前重命名列即可：
ALTER TABLE request_resources RENAME COLUMN resource to name;
或者可能发生迁移 post 升级：：
UPDATE TABLE request_resources SET name = resource where name is NULL;
ALTER TABLE request_resources DROP COLUMN resource;
柱 remote_user_agent 添加到 request 桌子¶
版本 ：n/a，扩展仍为社区状态
Date ：2011年12月9日
颠覆修订 ：16634个
参考文献 ： GEOS-4872
这里不需要执行任何操作，因为Hibernate只需要将新列追加到表中。如果由于某种原因没有出现这种情况，可以手动添加列：
ALTER TABLE request ADD COLUMN remote_user_agent VARCHAR(1024);