Compatibility with jOOQ 3.15 and later #4727
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
shakuzen
force-pushed
the
jooq-unlock
branch
2 times, most recently
from
36916c3
to
1b4143d
Compare
shakuzen
force-pushed
the
jooq-unlock
branch
2 times, most recently
from
b3d9da5
to
32c8869
Compare
Implementing jOOQ's `DSLContext` interface was causing revlock and subsequently frequent breaking. Now that jOOQ OSS supported versions no longer work with Java 8, we cannot compile against them to update our implementation `MetricsDSLContext`. This switches to extending `DefaultDSLContext` instead which eliminates a lot of boilerplate implementation and should be more compatible. A sample has been added that runs the tests against the latest version of jOOQ to ensure MetricsDSLContext works with it while compiling against the newest OSS version of jOOQ that supports Java 8.
|
It looks like since jOOQ 3.17, open source versions only support Java 17+. I've updated the sample to only run with 17+. |
Closed
shakuzen
commented
Feb 8, 2024
| * @author Jon Schneider | ||
| * @author Johnny Lim | ||
| */ | ||
| class MetricsDSLContextTest { |
There was a problem hiding this comment.
This class is copied from micrometer-core with only import/JavaDoc changes.
| @@ -136,4972 +116,678 @@ public DSLContext tags(Iterable<Tag> tags) { | |||
| } | |||
|
|
|||
| @Override | |||
| public Schema map(Schema schema) { | |||
| return context.map(schema); | |||
| public <R extends Record> SelectWhereStep<R> selectFrom(Table<R> table) { | |||
There was a problem hiding this comment.
Any specific reason this is not
Suggested change
| public <R extends Record> SelectWhereStep<R> selectFrom(Table<R> table) { | |
| public <R extends Record> SelectWhereStep<R> selectFrom(TableLike<R> table) { |
?
There was a problem hiding this comment.
Because we compile against jooq 3.14 and TableLike does not exist in that version.
This pull request was closed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Implementing jOOQ's
DSLContextinterface was causing revlock and subsequently frequent breaking. Now that jOOQ OSS supported versions no longer work with Java 8, we cannot compile against them to update our implementationMetricsDSLContext. This switches to extendingDefaultDSLContextinstead which eliminates a lot of boilerplate implementation and should be more compatible. A sample has been added that runs the tests against the latest version of jOOQ to ensure MetricsDSLContext works with it while compiling against the newest OSS version of jOOQ that supports Java 8.Resolves gh-3828
Obviates gh-4508 for now
This does break binary compatibility, as reported by japi. I think that's going to be unavoidable given the circumstances and it is limited to the jOOQ integration. Users will need to recompile their code that uses
MetricsDSLContext. I am not aware of any libraries that configure the jOOQ integration, so it should mostly be used in application code, making the recompile requirement less of an issue. Typical practice is to recompile application code when changing dependency versions.