Andreas, Thank you for sharing your experience. First of all let me stress that I also believe the HS developers do a great job. It is a great tool that is invaluable to us. I only wish we could have a bit shorter and more predictable release cycle, especially in situations where the current release version contains non-trivial bugs.
Unfortunately using the development branch is not an option for us. Escrow clauses in some of our license agreements compel us to maintain an up to date repository of our software binaries and all required libraries and run-times. Additional clauses prohibit the use of any pre-release versions or outdated versions of libraries or run-times. Apart from that our software is a multi-tenant server system that is used in 24/7 production environments making upgrades tricky. Our use-case is quite specific. Users create projects on the fly and each of those is a script + data-repository that is a clone of one of the project templates. Each template (and each copy thereof) is a self-containing system that has its own user interfaces and resources including an embedded H2 database. Since a couple of thousand of such projects are "active" at the same time the core server application instance dynamically loads/unloads them on-demand. We use a multi-database/url connection pool that does something similar with database connections, resulting in an average of ~50-200 concurrent connections to ~10-50 databases. Although some of these database are several Gb in size most of them are quite small. A manual dump/restore is already possible but since it is in-process the same H2 version is used for the SQL dump and the recreation of the database. Perhaps if there would be an easy trick to use 1.4.200 for dumping and then 2.0.201 for recreating we could build this into the connection pool and do this on demand. It would be great if we could somehow use both versions simultaneously inside the same process or if there would be sufficient backward compatibility built-in for doing an SQL-dump of an older database from inside a newer H2. On the upside I have managed to steer us clear of Oracle and SQLServer. Postgres served us well in days long gone by but for our copy-and-open-unlimited-databases-simultaneously use case there is no better match than embedded H2. To be fair HSQLDB also works fine but it is a lot slower than H2 in my experience. Cheers, Silvio On Tuesday, 23 February 2021 at 14:33:02 UTC+1 wuu...@gmail.com wrote: > Don't hesitate to use H2 not only for < 100k records. It can handle far > more. But upgrade may produce issues, so be careful. > > wtorek, 23 lutego 2021 o 02:47:55 UTC+1 and...@manticore-projects.com > napisał(a): > >> Silvio, >> >> we are in a very similar situation. Banking software, financial >> accounting, not really the place where you want to experiment a lot. Our >> large customers all run Oracle (which deserves its own place in hell) but >> for smaller banks less than 100k accounts H2 can provide a nice alternative. >> I am actually happy to hear from you because sometimes it looks like not >> many other people/companies run H2 in a similar scenario. >> We also have to put a lot of effort in versioning and upgrading our own >> VBox software accross various customers and so are aware of the burden, >> which any kind of versioning, backward compatibility and migration actually >> is. >> >> So with all understanding for the developpers and the scarce resources, >> from an end-user's point of view the current versioning schema is not >> optimal and we were close to abandon H2 once simply because the maintenance >> and upgrading procedure became too cumbersome. >> >> Eventually we have decided for ourselves, that there is no actual >> reliable version schema: We have experienced the current 2.0.201+ >> development branch as much more robust and stable and correct than 1.4.200 >> and also there were many "breaking changes" in between (e. g. new reserved >> keywords, NEXTVAL vs. NEXT VALUE FOR etc.) that for us it works better to >> be as close as possible to the upstream development. We see H2 now as an >> very agile, rolling realise software. >> >> I believe, the H2 developpers doe a fantastic job regarding the software >> itself but seem to lack experience or interest in practically running/using >> H2 in a corporate environment as a replacement for Postgres or Oracle. >> Maybe this is just out of scope. >> >> My advise: If you stick with 1.4.200 longer, you will likely face a big >> migration effort in your own software/Schema Definition when switching to >> 2.0.201 eventually. >> Consider using 2.0.201 and establish a weekly procedure of exporting to >> SQL script and re-importing into the next version, followed by a large >> batch processing test including reports. This works for us at least and has >> reduce the headache. >> >> Best regards >> Andreas >> >> >> >> On Mon, 2021-02-22 at 16:24 -0800, Silvio wrote: >> >> We use H2 in production heavily and would love to upgrade but as long as >> there is no actual version released we can only use 2.0.x for testing >> purposes. If only we could get some ball park estimate about when 2.0.201 >> will be released with some highlights of improvements we can expect and >> preferably some information about compatibility (or lack thereof) with >> 1.4.200 that would be great. We are planning the roll-out of a major new >> version of our software which will involve major customer data migrations. >> If a production release of 2.0.201 is imminent we could adjust our release >> schedule to include the upgrade. If it will take another 6-12 months we >> cannot. But as it is we can only guess which, to be honest, really sucks. >> >> On Monday, 22 February 2021 at 06:37:13 UTC+1 >> and...@manticore-projects.com wrote: >> >> Good Morning. >> >> On Sun, 2021-02-21 at 21:32 -0800, ciphe...@gmail.com wrote: >> >> rying a development version of H2 from Github? >> >> >> >> While I am not a H2 Developper and can only speak for my own experience: >> >> Running several large H2 databases we have had similar corruption issues >> with 1.4.200+ and never again since we switched to 2.0.201+ (until >> Feb/March 2020). >> In my opinion, the current 2.0.201+ snapshot is the most robust and >> correct H2 database and I prefer this "unstable" develepmoent snapshot over >> the actually released versions. >> >> Best regards >> Andreas >> >> -- >> You received this message because you are subscribed to the Google Groups >> "H2 Database" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to h2-database...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/h2-database/00a5d74e-6a53-4ebd-a9a5-0b9af8fecfc3n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/h2-database/00a5d74e-6a53-4ebd-a9a5-0b9af8fecfc3n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> >> -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To unsubscribe from this group and stop receiving emails from it, send an email to h2-database+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/h2-database/40aa07e4-eeae-4409-8a0d-34c348e5936en%40googlegroups.com.
