H2 upgrade notes

WARNING: this is a work in progress, not yet meant to be a plan, not yet meant to be discussed in public. If you stumble into it and are interested in helping please send me a private message.

---

Upgrading H2

GeoTools, GeoWebCache and GeoServer depend on a old version of H2, 1.1.119, while the current version, at the time of writing, is 1.4.197. The reason for such an old version is that H2 has changed storage format more than once, with newer version being unable to read an older version, but requiring a full dump to SQL and restore to upgrade the version. This can be also automated adding an extra JAR in the classpath (basically coupling an older version of H2 with some utility to automate the dump and restore).

The upgrade is becoming important as the version we are using is not compatible anymore with the java.sql expectations and is preventing, as an example, upgrade of the DBCP connection pool to a newer version (due to lack of JDBC methods that are expected, but not available, in the old H2 implementation).

H2 usages

GeoTools, GeoWebCache and GeoServer are using H2 for various reasons. A list (might not be complete, please double check):

• As a small embedded spatial datastore, based on H2 and HatBox. This is pretty much the only database that has tests enabled all the time, providing the first line of defence against breaking changes in JDCDataStore.
• The above datastore is not used much as a vector data store, but sees significant usage in ImageMosaic and NetCDF, leaving a lot of small databases sprinkled. It's also used in GeoServer whenever we need to test database specific behavior, to avoid having to rely on an external database
• GWC and GeoServer uses H2 as a common (and default) store implementation for the disk quota subsystem. This is direct usage, does not go through the above datastore
• GeoServer uses H2 in various places. In addition to the ones already cited above, it offers a store plugin for the geotools JDBC H2 module, the GeoFence plugin uses it as the default rule storage option for rules, while the KML module uses H2 databases to store the super-overlay hierarchy. Among the community modules, the jdbcconfig datastore also uses H2 for tests and as possible storage implementation (unusual), monitor-hibernate uses H2 by default to store request history and details, while the WPS JDBC status store for asynch process status can use it as a simple status store (unusual).

The above means that a typical usage of GeoTools, GeoWebCache and GeoServer might depend on a number of small H2 databases distributed in various places, making a manual upgrade a daunting task.

Upgrading gt-jdbc-h2

These are the findings obtained by simply changing the H2 version in GeoTools and running the tests:

• Relative paths not starting with "." are no longer supported, e.g., "target/geotools" used to be supported, but now it has to be "./target/geotools"
• The column type for Geometry, as reported by the driver, switched from BLOB to OTHER. In GeoTools this is an easy fix, but it also breaks all tests creating new tables and requires a change in the HatBOX library.

Switching to H2GIS

H2GIS is licence compatible now and an interesting option to have. However, it's not a seamless upgrade and we have databases distributed around that would have to be upgraded manually (conversion process to be determined). If someone is interested, the ideal would be to create a new store implementation in GeoTools that can be used "fresh". There is a possible starting point here, although by the looks of it the test coverage, is at the time of writing, low compared to the battery of tests available in GeoTools.