Jooq: Support additional Settings.interpreterDialects and add an InterpreterConnectionProvider SPI

[lukaseder]

We've introduced a new Settings.interpreterDialect flag (https://github.com/jOOQ/jOOQ/issues/9362), which can be used to specify how we're interpreting DDL statements. Currently supported options are:

• H2 (what was available prior to 3.13)
• DEFAULT (our new DDL interpretation)

We also want to support:

• [x] Other in-memory database dialects, such as Derby, HSQLDB, SQLite, which can be made available simply by having the relevant JDBC driver on the classpath
  
  
  
  • [x] DERBY
  
  
  • [x] HSQLDB
  
  
  • [x] SQLITE
  
  
• [x] All other dialects, by either looking for test containers on the classpath, or using some new InterpreterConnectionProvider JDBC connection that users can provide through an SPI

[lukaseder]

We need a new kind of ConnectionProvider in Configuration. I knew we'd eventually run into this problem, where Configuration would hold two different instances of the same type:

• Configuration.connectionProvider(): ConnectionProvider: The ConnectionProvider used for ordinary querying
• Configuration.interpreterConnectionPrrovider(): ConnectionProvider: The ConnectionProvider used for DDL interpretation

Both methods return the same type ConnectionProvider, but with a different semantics. Note, this will happen once more with https://github.com/jOOQ/jOOQ/issues/8194

This isn't a problem for the getters above, but what about the setters? I chose not to follow JavaBeans conventions here, but overload derive() and set() methods, based on types. With equal types, this won't work in this case.

What are the alternatives?

• deriveInterpreterConnectionProvider() and setInterpreterConnectionProvider() (the latter will be added to DefaultConfiguration anyway.
• A nested Configuration.interpreter() configuration object that contains the relevant references.
• others?

Thoughts, @knutwannheden ?

[lukaseder]

First implementation draft only uses DefaultConfiguration.setInterpreterConnectionProvider() and does not yet expose this setter in the Configuration API. This is workable and allows for postponing the naming discussion.

[knutwannheden]

Yes, very unfortunate. I suppose you already dismissed the idea of having a nested InterpreterConfiguration?

[lukaseder]

Yes, very unfortunate. I suppose you already dismissed the idea of having a nested InterpreterConfiguration?

That does not sound desireable. Would it have a separate set of Settings? Would users expect the nested TransactionProvider to apply? Would they expecte ExecuteListeners to work independently?

[knutwannheden]

No, it would be owned by the Configuration object and only contain interpreter-related configuration. But that doesn't fit in with the current API.

[lukaseder]

Oh, I see. That's indeed an option I wouldn't dismiss right away, although it seems to be more difficult to design correctly (at least in the short term) than the alternatives I'm hoping for.

[lukaseder]

I think your suggestion might not be the best for the current Configuration design, but it might be a good option in the future, when we want to re-design Settings as well, see: https://github.com/jOOQ/jOOQ/issues/9167

When we re-design Settings, we might as well re-design Configuration

[lukaseder]

It's now possible to interpret DDL using the in-memory mode of any of:

• Derby
• H2
• HSQLDB
• SQLite

[lukaseder]

We're now ready to tackle https://github.com/jOOQ/jOOQ/issues/6551