Hi all, as you probably know, GeoServer has a core dependency on H2 database version 1.1.119. This is slowly becoming troublesome for a few reasons:
- The 1.x series of H2 is abandoned - It's accumulating CVEs, while none of them seems to be affecting our current usage, they still show up in all dependencies reports So it would be a good idea to upgrade. H2 version 2 is supported, but it poses serious upgrade problems: the format of the database changed, and H2 has no compatibility with 1.x databases. The only way to upgrade is to dump SQL using the older version, and then restore with the newer one. In addition, H2 retained the same package names, meaning we cannot have both in the same classpath (unless we use shading). To make things worse, H2 1.x did not have spatial data types, so we have WKB stored in the database as binary columns, with spatial indexing provided by extra libraries that also happen to be dead (hatbox, geodb). In GeoSolutions we have been trying to organize an upgrade for a while, but it turns out it's too much work to be done in one shot (clear funding issue). However, there is an easier path... chipping away at it a few dependencies at a time. Turns out some of the dependencies towards H2 are core, and others are in plugins. The one that really need a spatial database are just in plugins, while the core dependencies need only an alphanumeric database: - GWC disk quota mechanism - KML superoverlay support (is anyone still using it? 😁 In both cases the databases collect caches of information that can be rebuilt automatically by GeoServer as needed, so no actual migration procedure is needed: we can drop the old database, and start over with a new one. Disk quota over H2 is not recommended for production environments, but still, to keep our "ease of use" story going, having an embedded database would be a good thing. So what we propose is easy: for these two use cases we switch the embedded database usage to HSQL, which has been modestly, but steadily, serving our CRS database needs for years, without causing trouble. It's already in our classpath, it has been used for a long time, it's pure java, and it's small (1.6MB). Alternatives considered and discarded for the task at hand: - Sqlite/Geopackage: the sqlite jdbc library is a beast (12.2 MB and growing) and not part of the GWC dependencies. - H2 v 2.x, because it would mean shading it and right now we'd have to either shade all other usages of 1.x (can't cover that) or shade 2.x (which is the opposite of the direction we're going) Removing the need for H2 In the core will also allow the possibility of running GeoServer along with the H2GIS data store (that already depends on H2 v 2.x). The other places where we need an embedded spatial database may be covered, in time, by GeoPackage, until we can wave goodbye to the last usage of H2 v 1.x, but they will be doable one by one and at their own pace: GeoFence, NetCDF store. Other non spatial cases that are in plugins, which might be migrated later to either GeoPackage or HSQLDB, are wps-jdbc and importer-jdbc (both depending on the DataStore interface) and jdbcstore/jdbcconfig. One thing that will eventually have to go is the H2 datastore we offer as an extension. I don't think it has any traction, but we use it for some tests. I'd suggest we start removing it from the downloads, though. Feedback/opinions? W'd like to start migrating GWC and KML substystem as soon as possible. And oh, I started a mail discussion rather than writing a proposal because there is one bit in here that is totally against the proposal requirements: having a fully funded plan. What we can offer is a vision/direction and a first stepping stone, but we won't be able to cover the full elimination of H2 v1.x (as said, too much work to fund it in one shot, and a small audience of interested parties). Cheers Andrea == GeoServer Professional Services from the experts! Visit http://bit.ly/gs-services-us for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions Group phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 https://www.geosolutionsgroup.com/ http://twitter.com/geosolutions_it ------------------------------------------------------- Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail
_______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
