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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/h2-database/a0b8d0ba-63a4-49d2-ae7f-baf23822c234n%40googlegroups.com.
