Log warning when unsupported dialect version is being used

[lukaseder]

Flyway has this cool feature where a warning is logged, when an unsupported (not yet or not anymore supported) dialect version is being used. This helps better assess whether users can expect a given RDBMS version / jOOQ version combination to work, and whether they will be able to get support for it.

We can use JDBC's DatabaseMetaData.getDatabaseMajorVersion() and DatabaseMetaData.getDatabaseMinorVersion() for this, or run a query against the various v$version or similar tables ourselves.

Minor releases receiving this upgrade:

• 3.18.0
• 3.17.9
• 3.16.15

This is a codified version of our support matrix: https://www.jooq.org/download/support-matrix. As such, only versioned dialects will receive this increment, including:

• Db2
• Firebird
• MariaDB
• MySQL
• Oracle
• PostgreSQL
• SQL Server
• SQLite
• Sybase ASE

The above link will be included in the warning message. If there's no warning, an info message can still be logged, confirming that the RDBMS / jOOQ version combination is supported.

[lukaseder]

Fixed in jOOQ 3.18.0, 3.17.9 (#14638), and 3.16.15 (#14639)

[lukaseder]

The current implementation detects when a database version is too old for the configured dialect.

Might be worth logging also when a database version is too recent for the configured dialect, at least as INFO message. The risk of getting something undesired is much smaller this way, but it helps assess whether jOOQ should be upgraded.

[lukaseder]

For now, the "too recent" message won't be logged

[monosoul]

@lukaseder I get this with jOOQ 3.18.0:

Version mismatch         : Database version is older than what dialect POSTGRES supports: 14.5. Consider https://www.jooq.org/download/support-matrix to see what jOOQ version and edition supports which RDBMS versions.

Which is, I guess, an unexpected behavior, since minimum PG version for jOOQ 3.18.0 is 14.

[lukaseder]

Thanks for the pointer, @monosoul. The support matrix is now updated. There was a task to fix it post release of 3.18, which was forgotten. The PG requirement of the jOOQ Open Source Edition 3.18.0 is PostgreSQL 15.

[lukaseder]

Support matrix here: https://www.jooq.org/download/support-matrix

[A248]

Would it be possible to have a system property or other method to toggle off this warning? I am entirely aware of the support matrix; however, for my situation, JOOQ's warning happens to be redundant. The clients using my software deploy a variety of database versions, so I inspect the version myself and encourage them to upgrade.

It is true that some of my clients insist on operating a RDMS with a lower version than JOOQ supports. However, every SQL query in my application is integration-tested against the swathe of database versions. Thus, even if JOOQ OSS doesn't officially support an older RDMS, I make sure that every SQL query is compatible by avoiding syntax introduced in newer RDMS versions.

So you know, I gain no income or other revenue stream from this software -- it is FOSS -- and charging a JOOQ license for clients is wholly unfeasible. If, nevertheless, you are displeased by my usage of JOOQ OSS in this way, do let me know, and perhaps we can work toward a solution. I know JOOQ OSS is licensed under Apache 2, however, I would nevertheless like to confirm to the spirit and letter of JOOQ's official policy.

[lukaseder]

Thanks for your message, @A248. You can configure your logger to have a higher threshold than warning for this message. Its name is org.jooq.impl.DefaultExecuteContext.logVersionSupport.

I don't think adding additional flags per log message will scale. Loggers make this already convenient enough.

So you know, I gain no income or other revenue stream from this software -- it is FOSS -- and charging a JOOQ license for clients is wholly unfeasible. If, nevertheless, you are displeased by my usage of JOOQ OSS in this way, do let me know, and perhaps we can work toward a solution. I know JOOQ OSS is licensed under Apache 2, however, I would nevertheless like to confirm to the spirit and letter of JOOQ's official policy.

I'm not sure why you'd think so. There are no strings attached to jOOQ's ASL 2.0 license.

This message helps users make more informed decisions, earlier. Few users integration test all their queries, so they might run into trouble and surprises only later on when they deploy an upgraded application. A frequent issue was MariaDB 10.5 INSERT .. RETURNING usage by jOOQ:

• Insert statement fails on new version of Jooq and older mariadb #10799
• Generated DAO tries to use INSERT...RETURNING on unsupported MariaDB version #10892
• And many others

After answering many support requests about MariaDB INSERT .. RETURNING, I thought I could make users aware of this earlier on, as they probably simply aren't aware of jOOQ's RDBMS version support matrix.

In the past, I've noticed that Flyway does the same thing, and thought that a majority of users will find this information useful.

[A248]

Hi Lukas. I had discovered the logger name, and I understand the warning is of much use to you in preventing unnecessary support requests. I have dealt with many support requests myself due to users relying on outdated software.

However, if I allow the warning to appear, then I will receive numerous support requests from users on older RDMSes which happen to be supported by my software but not JOOQ. An unfunded OSS project cannot sustain this.

Unfortunately, I am in somewhat of a predicament with respect to logging configuration. You see, I have no control over clients' logging frameworks -- they employ multiple. This compels me to resort to changing JooqLogger's global threshold to ERROR, which is prone to cause future headaches by hiding other messages. JOOQ already provides the system properties org.jooq.no-tips and org.jooq.no-logo to silence their respective log messages (forgive my use of the latter; I promise its necessity). Might we have a similar system property for the dialect version warning?

[A248]

A fun fact. I also rely on Flyway. They do not simply log when an unsupported version is used on their OSS offering. Rather, they throw an exception.
https://github.com/flyway/flyway/blob/60a5ad1900fced203bd55b83cb5c857a7f452895/flyway-core/src/main/java/org/flywaydb/core/internal/database/base/Database.java#L127

[lukaseder]

However, if I allow the warning to appear, then I will receive numerous support requests from users on older RDMSes which happen to be supported by my software but not JOOQ. An unfunded OSS project cannot sustain this.

Can you point to a few examples of this? I would like to get a feeling of the importance of this change. Obviously, adding one more flag is little effort for jOOQ, but if we start creating precedents for people liking/disliking individual log messages and requesting more and more flags, well, you know how this won't scale.

A fun fact. I also rely on Flyway. They do not simply log when an unsupported version is used on their OSS offering. Rather, they throw an exception.
https://github.com/flyway/flyway/blob/60a5ad1900fced203bd55b83cb5c857a7f452895/flyway-core/src/main/java/org/flywaydb/core/internal/database/base/Database.java#L127

I believe that only happens when the RDBMS is really too old, i.e. unsupported in all editions and distributions?
https://github.com/search?q=repo%3Aflyway/flyway%20ensureDatabaseNotOlderThanOtherwiseRecommendUpgradeToFlywayEdition&type=code

[lukaseder]

OK, much rather than discussing this particular log message, why not solve this dynamically and generically for all jOOQ logs: #15050

I can definitely see doing this generic improvement, rather than adding more individual flags.

[lukaseder]

Note, we already have a mechanism that allows users to turn off loggers using reflection. You can access the JooqLogger and set its internal JooqLogger.supportsWarn flag to false. I believe that was introduced for similar reasons, a long time ago. Does the reflective approach work for you as a workaround?

[lukaseder]

#15050 has been implemented for jOOQ 3.19.0. For jOOQ 3.18.0, I believe the reflection workaround should suffice.

[A248]

Hi Lukas, thanks. These solutions are quite sufficient, especially the generic system property. Very appreciated.

-- A248