Hi Matthias, Thank you very much for your nice words. I will comment on your questions inline:
On Thu, Aug 29, 2019 at 9:50 PM Matthias Kurz <[email protected]> wrote: > - The Java 11+ supporting distribution, "which includes more optimal API > usage, depending on new Java 9-11 APIs" - can you be a bit more specific? > Which newer JDK APIs are leveraged? Examples? > First off, for the avoidance of doubt, both the Java 8+ distribution and the Java 11+ distribution *support* Java 11 starting from jOOQ 3.12. We already integration tested jOOQ 3.11 with Java 11, but did not officially support it. Starting from jOOQ 3.12, we wanted to be able to use new API in one of our distributions. Two such API usages that I can remember right now are: - The java.util.concurrent.Flow API, for the new reactive integration. While the industry has standardised reactive APIs to be backed by the reactive streams SPI, the JDK has cloned the creative streams SPI in Flow. We're expecting third party libraries to slowly migrate towards Flow, and we wanted to be ready for that already today. For users, it is transparent whether jOOQ's ResultQuery implements org.reactivestreams.Publisher or Flow.Publisher, or both. - Some reflection APIs have changed incompatibly in Java 9, especially when trying to reflectively call default methods on proxies. It is not possible to get this right on Java 9+ without calling the new APIs using e.g. MethodHandles::privateLookupIn We'll find additional API in the future that we'll be able to use for whatever reason in the Java 11+ distribution only. Regarding distributions and editions, we only want to offer a single jOOQ Open Source Edition distribution. We had two options: - Make it support Java 8+ - Make it support Java 11+ Java 11 is not adopted well enough yet to bump the jOOQ Open Source Edition's dependency to Java 11, so we picked Java 8. The commercial editions have several distributions now, supporting: - Java 6 - 7 (Starting with 3.12 for Enterprise Edition only - the websites will be updated soon to reflect this change) - Java 8 - 10 (All commercial editions) - Java 11+ (All commercial editions) > - Can you give examples for the procedural language API? How does that > work? > We will soon update the manual and blog about it in much detail. In essence, with jOOQ 3.12, you can write anonymous blocks such as PL/SQL's: DECLARE i INT := 0; BEGIN WHILE i < 10 LOOP INSERT INTO t (col) VALUES (i); i := i + 1; END LOOP; END; Or with jOOQ: Variable<Integer> i = var(unquotedName("i"), INTEGER); ctx.begin( declare(i).set(0), while_(i.lt(10)).loop( insertInto(T, COL).values(i), i.set(i.plus(1)); ) ).execute(); You can also parse parts of it using DSLContext.parser().parseStatement(), and combine the resulting statement expression with other, dynamic jOOQ logic. This API is our first step towards pushing more complex logic into the database in a vendor agnostic way. We're already emulating quite a few things in these anonymous blocks (will be documented in the manual and blog post), and we'll continue evolving the API using procedure definition APIs, trigger APIs, etc. An exciting new area for jOOQ! - Native JSON/JSONB support: Can you show an example? > We'll also blog about this soon. The code generator will pick up these types automatically and produce a Field<JSON>. This just takes care of writing the right binding / reading code, such that e.g. in PostgreSQL, you no longer have to do that manually. The new org.jooq.JSON and org.jooq.JSONB types are currently just wrappers for String data. > - You write "...immutable query object model, with all the secondary > benefits like caching of generated SQL..." Is this "immutable query object > model" in internal change? Is there a (new) user facing API? > At first, this will be an internal change, although we will make the API public from the beginning, for early user feedback. Then, it will turn into a new user facing API and replace the current "model API" (SelectQuery, UpdateQuery, etc.) as well as obsolete the VisitListener. The goal is that users will be able to: - Construct jOOQ queries entirely using this model, instead of the DSL, where this makes sense (in more sophisticated use cases) - Transform the queries using this model using pattern matching or other techniques (imagine matching all ACCOUNT tables and replacing them by (SELECT * FROM ACCOUNT WHERE CUSTOMER_ID = ?) derived tables for row level security) We don't have any preview yet. We'll evaluate numerous options, including: - Writing this API in another JVM language that already supports ADTs and pattern matching, e.g. Scala or Kotlin - Writing this API in Java with a strong forward compatibility focus for the goodies we'll get with Amber (record types, sealed types, pattern matching) and Valhalla (value types) We don't know yet. > And: Will generated SQL be cached internally now somehow (or was that the > case already)? > We'll start caching SQL fragments or entire SQL statements for improved performance. We currently cannot do that for any jOOQ QueryPart because: - QueryParts are mutable, hence it is almost impossible to detect in any QueryPart if any sub-QueryPart was modified since the SQL string was cached - Configuration and Settings are mutable, and they define things like SQLDialect, render mapping, upper/lower case keywords/identifiers, etc We could have made some heuristics and document a very complicated and buggy cache, but we opted for simply not caching generated SQL. In the future, with this new query object model, it will be possible for users to treat SQL queries (even dynamic ones) as constants and reuse the SQL string that is generated only once for the entire application. This is also possible today, but only with manual plumbing on a per-query basis. We'll expect a tremendous performance improvement in the client from this. Thanks, Lukas -- You received this message because you are subscribed to the Google Groups "jOOQ User Group" 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/jooq-user/CAB4ELO53GQS1GOuf%3D0rdXd62FPK%2BwV2srq4qif6KyahFR0Gh0Q%40mail.gmail.com.
