Thank you for the useful discussion. :) Sorry for my long absence, I was not able to find the bug myself, so I come back without a patch, and will consider instead migrating to the development version.
Silvio kirjutas neljapäev, 25. veebruar 2021 kl 00:59:45 UTC+2: > Hello Andreas, > >> >> >> I do understand your legal requirements, however in my opinion it is an >> illusion that sticking with 1.4.200 was compliant with these requirements: >> The H2 developpers stated clearly that each version is just a snapshot of >> the development branch (in numerical order) and that there was no support >> or bug-fixing for older releases. >> >> In fact, all errors we found and reported were affecting 1.4.200 but have >> been fixed in the development branch 2.0.201 (only). >> If you found the reason for the mentioned corruption and published a >> patch, then I doubt they would release another 1.4 version. >> You could fork your own H2 repository though and just release H4-1.0 >> though in order to be escrow compliant. (In fact we have been discussing >> that internally already because of the "release schedule"). >> > > Generally speaking you are correct. I know that H2 has no bug fixing on > released versions and the release mechanism is "forward only". But we have > specified this explicitly in our contracts and have restricted ourselves to > versions that were deemed release worthy by the H2 devs and presented as > such on the website. At that time (I am speaking about the 1.2.x and early > 1.3.x period) releases where much more frequent so that gave us ample > leeway. I wish they would just in name release some of the more stable > snapshots. I need no specific guarantees about stability as the currently > released version also fails at times. We have built all kinds of safe > guards around that already (going as far as doing redundant transaction > logging that enables us to completely recreate a database with all its > contents when it gets wrecked with close to zero data loss). > > In theory we could renegotiate but as you probably know it is often risky > to try to renegotiate terms that where once accepted and never looked at > again if they are favorable to you already. > > >> >> At this part you could expect some effort on your end when switching to >> 2.0.201: they introduced some more Preserved Keywords (which broke our >> age-old Schema Definition) and also (re-)moved some Oracle compatibility >> from the H2 mode into the Oracle Mode strictly (NEXT VALUE FOR vs. >> NEXTVAL). We had to rewrite a few statements and also change our code >> around Sequences. Maybe some other stuff I do not recall. >> > > Our database abstraction layers should shield us from most changes. SQL > statements use fully quoted names and we do not use sequences. Earlier H2 > versions used to incorrectly drop quotes from DDL statements internally > serialized by H2 giving us errors when reopening such databases but the > devs solved that quickly in the next release at the time. > > >> >> We have been facing similar challenges and so have built our own >> migration tool: https://github.com/manticore-projects/H2MigrationTool >> There is a Command Line mode and an UI. If you want to integrate it into >> the connection pool, you can strip the UI and use the static method: >> >> MigrationTool.migrate( >> >> String versionFrom, >> >> String versionTo, >> >> String databaseFileName, >> >> String user, >> >> String password, >> >> String scriptFileName, >> >> String compression, >> >> String upgradeOptions, >> >> boolean overwrite, >> >> boolean force) >> >> throws Exception >> >> >> It supports migration of DB folder, which can contain may H2 DBs. >> >> > That could be very useful to us if we could do this in a separate class > loader so we can have one (or several threads) converting databases while > having the main server working with already converted databases using > 2.0.201. > > >> >> Have a look into the code, it shows how to manage the different H2 >> Drivers and load/unload them dynamically. >> > > Thank you. I will. > > >> >> So true. Although I must say that only H2 2.0.201 provides the important >> features neded for a Oracle replacement: working table links and WITH >> clauses. >> And I am still missing the SQL Tuner and a proper execution plan (I know, >> I am dreaming). >> >> For us, even more important is the "Oracle compatibility" in H2. While >> our product is RDBMS agnostic and works with all major DBs, each product >> will need its own handling or SQL statement where not compliant with the >> standard. >> In case of H2 compared to Oracle, we do not need any particular >> adjustments any more (since 2.0.201), while MS SQL Server has basically its >> own DDL/query definition file. >> Running the same software and SQL on Oracle (on large servers) and H2 (on >> a 2 core 4GB virtual machine) is unparalleled and priceless. >> > > We also target multiple RDBMS systems but H2 is one of the primary targets > in the abstraction layer so we do not use any of its compatibility modes. > And apart from HSQLDB we do not actively use any of the other currently > supported systems (PostgreSQL, SQLServer, MySQL) any more. I never bothered > to include Oracle. I used that quite heavily in the 8.x/9.x days and that > was enough for me to never touch it again. > > Thanks again for sharing your thoughts. I will certainly look into your > conversion tool and will report back here with whatever we come up with. > > And I am still hoping to hear something soon about what we can expect the > coming months... > > Kind regards, > > Silvio > > > >> -- 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/a0b8d0ba-63a4-49d2-ae7f-baf23822c234n%40googlegroups.com.
