On Mon, 15 May 2023 at 11:32, Andrea Aime <andrea.a...@geosolutionsgroup.com> wrote:
> 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). > All this sounds great, my only passing thought re funding is that this is probably a better use of our osgeo funding than removing opengis but I don't know if we could swap out the end goal of that funding. Is this something we could do in a weekend code sprint in say Kosovo? Ian > > 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 > -- Ian Turton
_______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
