Artifact for community-dialects

[beikov]

At the last PR-Meetup we found a few more PRs that want to add Dialects for certain databases and we discussed the idea about creating a separate artifact/module that contains such community contributed Dialects. This was also discussed on Zulip where we were coming to a similar conclusion, that a separate artifact might be a good way forward.

So the main concerns for adding/keeping a Dialect to hibernate-core so far were:

• Who maintains it? Maintenance of the Dialect regarding bugs/features and DialectChecks for tests
• Who tests it? Run the testsuite to verify the Dialect works, ideally as Jenkins node connected to ci.hibernate.org

We maintain and test certain Dialects for the big databases, so they are part of hibernate-core:

• H2
• Derby
• DB2
• MySQL
• Oracle
• PostgreSQL
• MariaDB
• SQL Server

Some Dialects are part of hibernate-core because the vendors help with the maintenance and testing by e.g. providing a Jenkins node:

• SAP HANA
• Spanner
• Cockroach
• Sybase

We also have a few Dialects for historic reasons that we don't want to remove from hibernate-core (yet?):

• HSQL
• Ingres
• Informix
• Mimer
• CUBRID
• Teradata
• MaxDB
• RDBMSOS2200
• TimesTen
• Cache
• Firebird

Here are the PRs for new Dialects:

• SQLite HHH-10668 - Add SQL dialect for SQLite 3 #1874
• Impala HHH-14462 Impala dialect support for Hadoop #3743
• InterSystems IRIS HHH-12597 Support Hibernate Dialect for InterSystems IRIS Data Platform #2335

A possible way forward for new Dialects, and maybe also for some of the ones we currently have for historic reasons, could be to move them into a separate artifact e.g. hibernate-community-dialects that is part of the hibernate-orm Git repository. We would also do a community release for that, but we explicitly state that we do not provide support for these Dialects. These Dialects would be maintained on a best effort basis only. The community can provide PRs which the Hibernate team would consider, but the Hibernate team will not actively try to optimize such Dialects for performance or feature correctness.

The proposal is to do this for 6.0 and maybe also for 5.5 in case we decide to do that release.

What are your thoughts on this?

The proposal was accepted and will be implemented as part of https://hibernate.atlassian.net/browse/HHH-14693

[sebersole]

For completeness... another alternative is to simply reject such Dialect contributions that are not considered "important" or something we want to maintain.

[gbadner]

For the record, here is an article that shows EAP 7.x supported configurations: https://access.redhat.com/articles/2026253 .

Here are the tested DB configurations for EAP 7.3:

Database	JDBC Driver
IBM DB2 e11.1	IBM DB2 JDBC Universal Driver Architecture 4
Oracle 19c RAC	Oracle JDBC Driver v19
MySQL 8.0	MySQL Connector/J 8
MariaDB 10.1	MariaDB Connector/J 2
MariaDB Galera Cluster 10.1	MariaDB Connector/J 2
Microsoft SQL Server 2017	Microsoft SQL Server JDBC Driver 7
PostgreSQL 11.5	JDBC4 Postgresql Driver, Version 42
Enterprise DB Postgres Plus Advanced Server 11.6	Postgres Plus Advanced Server Driver 42
Sybase ASE 16 (SP02)	Sybase JDBC driver v16

RedHat tests all of the above DBs for Hibernate ORM versions that are included in RedHat products.

For sure, the dialects for the above DBs should remain in hibernate-core, or some other self-contained artifact that does not include dialects that are not tested.

I, personally, am in favor of moving all existing, non-tested dialects into a different artifact, such as hibernate-community-dialects that is part of the hibernate-orm Git repository. I suppose there could be business reasons for keeping particular non-tested dialects in hibernate-core. I will ask about that.

I'm not sure about doing this in Hibernate ORM 5.x though. Maybe starting in H6?

[gbadner]

To clarify, when I say "non-tested", I mean that it is not tested by either https://ci.hibernate.org/view/ORM/ or by QA on Hibernate ORM versions included in RedHat products.

[beikov]

I suppose there could be business reasons for keeping particular non-tested dialects in hibernate-core. I will ask about that.

The move would obviously change the fully qualified class names of the Dialects, but we could still support automatic Dialect resolution for these databases.

The proposal is to start with this in Hibernate 6.0, maybe also in 5.5 if we decide to do that release.

[gavinking]

An opinion I hold, which I can’t perhaps justify very well, is that we should continue to support the classic “old” legacy enterprise RDBMs, even when we don’t have that many people using them, by which I mean Ingres, Informix, and Teradata.

I guess I feel like the sort of systems which are still using these old things are quite likely doing something rather important.

[gavinking]

MaxDB might also fit in that category; I’m not sure.

[beikov]

So am I understanding that right, that you are arguing that these Dialects which I categorized under "part of hibernate-core for historic reasons" should remain in hibernate-core? I don't have a strong opinion but it feels to me that these Dialects should move to hibernate-community-dialects unless their vendors step up and help with maintenance and testing. We currently have no way to do automated testing for most of these Dialects and since we do not support these Dialects through EAP either, I don't see how these are different from a quality perspective to community maintained Dialects.

[gavinking]

Well I'm not sure if you could characterize what I wrote as an "argument" exactly. More of a prejudice in favor of big old creaky systems that shift real money around.

We currently have no way to do automated testing for most of these Dialects

Yes, sure, that is indeed a big problem.

[gavinking]

Does anyone know if CUBRID is widely used?

[beikov]

It seems it is still actively developed. Last release was in January 2021.

[gavinking]

Right, but do we have people using it with Hibernate, is the question.

[beikov]

Since I listed CUBRID in the "part of hibernate-core for historic reasons" list, I would treat it just like the others of that list. IMO we should just move them all to the hibernate-community-dialects artifact unless the vendor steps up. Even if the community uses these Dialects, IMO the differentiator for being in one or the other artifact should be the assured quality.

[dreab8]

I think the benefit of the new repository is to have a way to deal with new dialect implementations that is not just rejecting them. About the historic dialects I do not have a strong opinion, may be we can keep them all in core or decide to keep a subset of them and move the others to the hibernate-community-dialects repository but probably it is something we can decide later on.

[dreab8]

sorry my bad, do not why I was thinking to another repository :( sorry again for the confusion 🙏

[beikov]

Hmm, the argument about it being open source and easily testable could apply to e.g. SQLite as well, yet we concluded that we don't want to support it and thus would only move it to hibernate-community-dialects. Like you wrote, these Dialects aren't tested and thus not "blessed" so I personally would rather see them moved. That way, we can really differentiate between "blessed"/tested and the best effort maintained ones.

[sebersole]

What is the "compelling" part of SQLLite?

[gavinking]

The "compelling" bit is that it's very popular. And so at first I was surprised you didn't want it. But now I have a hazy recollection that when I went and actually looked at it, it was a bit rubbish or a bit not-really-useful-from-Java or something and then I didn't want it much either.

But I don't recall very well.

[sebersole]

I have never used it, nor really know anything about it. Andrea and Christian say it is used in highly embedded applications such as automotive and Android. No one is using Hibernate in those spaces.

[mrotteveel]

From the perspective of such a 'lesser' dialect (Firebird), I wouldn't have objections to moving things to a community-dialects solution, or even having to provide our own library (e.g. a org.firebirdsql:hibernate-dialect-firebird library or something like that). Such separate libraries might also be a way to track actual usage (e.g. using Maven Central statistics)

However, I vaguely recall (a long time ago, maybe 10 years or so) that I had some issues when trying to create a custom dialect in its own package because dialects relied on some package-private classes or methods. I'm not sure if that recollection is accurate nor if it still applies today, but it would be necessary for dialects to be able to live in a different package (if only for the Java module system requirements of not having the same package in multiple modules).

[beikov]

That's not a problem anymore. Dialects can live in external artifacts, so there should be no issue. The benefit of you providing the Dialect is that you can choose to support any Hibernate version even if we decide not to maintain that version anymore. So we definitely encourage vendors to provide their own Dialect.

[gavinking]

I vaguely recall (a long time ago, maybe 10 years or so) that I had some issues when trying to create a custom dialect in its own package because dialects relied on some package-private classes or methods

If that's the case then we should totally fix that, because Dialect has always been a published extension point, and so if it is the case it's certainly unintentional.

[mrotteveel]

That's not a problem anymore. Dialects can live in external artifacts, so there should be no issue.

That is good to know, and to be clear, it could be that I'm misremembering things here.

The benefit of you providing the Dialect is that you can choose to support any Hibernate version even if we decide not to maintain that version anymore. So we definitely encourage vendors to provide their own Dialect.

One thing to address would be things like https://github.com/hibernate/hibernate-orm/blob/wip/6.0/hibernate-core/src/main/java/org/hibernate/dialect/Database.java and replace or enhance that with a form of SPI / java.util.ServiceLoader form of discovery.

[beikov]

Yeah, I agree. I created https://hibernate.atlassian.net/browse/HHH-14478 for that.

[gavinking]

One issue with this is what happens with the code for guessing a dialect based on JDBC metadata. That's going to have to change somehow. The Dialects are going to need to know how to guess themselves somehow.

[beikov]

See https://hibernate.atlassian.net/browse/HHH-14478

[sebersole]

This is trivial to do.

For completeness, it should also recognize JPA's settings such as javax.persistence.database-product-name, javax.persistence.database-product-version, etc

[sebersole]

#3792