diff --git a/jOOQ-manual/src/main/resources/org/jooq/web/manual-3.10.xml b/jOOQ-manual/src/main/resources/org/jooq/web/manual-3.10.xml index eb667d7943..307dde8d94 100644 --- a/jOOQ-manual/src/main/resources/org/jooq/web/manual-3.10.xml +++ b/jOOQ-manual/src/main/resources/org/jooq/web/manual-3.10.xml @@ -8855,6 +8855,122 @@ condition("my_column IN ({0})", list(a, b, c)); // Using a single template ar +
+ SQL Parser + +

+ A full-fledged SQL parser is available from and from (see ). +

+ +

Goal

+ +

+ Historically, jOOQ implements an internal domain-specific language in Java, which generates SQL (an external domain-specific language) for use with JDBC. The jOOQ API is built from two parts: The where the DSL API adds lexical convenience for programmers on top of the model API, which is really just a SQL expression tree, similar to what a SQL parser does inside of any database. +

+ +

+ With this parser, the whole set of jOOQ functionality will now also be made available to anyone who is not using jOOQ directly, including JDBC and/or JPA users, e.g. through the , which proxies all JDBC Connection calls to the jOOQ parser before forwarding them to the database, or through the API, which allows for a more low-level access to the parser directly, e.g. for tool building on top of jOOQ. +

+ +

+ The possibilities are endless, including standardised, SQL string based database migrations that work on any SQLDialect that is supported by jOOQ. +

+ +

Example

+ +

+ This parser API allows for parsing an arbitrary SQL string fragment into a variety of jOOQ API elements: +

+ + + +

+ The parser is able to parse any unspecified dialect to produce a jOOQ representation of the SQL expression, for instance: +

+ + query = +DSL.using(configuration) + .parser() + .parseResultQuery("SELECT * FROM (VALUES (1, 'a'), (2, 'b')) t(a, b)")]]> + +

+ The above SQL query is valid standard SQL and runs out of the box on PostgreSQL and SQL Server, among others. The jOOQ ResultQuery that is generated from this SQL string, however, will also work on any other database, as jOOQ can emulate the two interesting SQL features being used here: +

+ + + +

+ The query might be rendered as follows on the H2 database, which supports VALUES(), but not derived column lists: +

+ + + +

+ Or like this on Oracle, which supports neither feature: +

+ + + + +
+
Names and identifiers @@ -12914,12 +13030,43 @@ public class DeleteOrUpdateWithoutWhereException extends RuntimeException {}

Since jOOQ 3.0, a simple wrapping API has been added to wrap JDBC's rather awkward . This API is still experimental, as the calls to the underlying JDBC type are not always available for all SQL dialects.

- -
+ + -
- Logging - +
+ Parsing Connection + +

+ As previously discussed in the , jOOQ exposes a full-fledged SQL parser through , and often more interestingly: Through . +

+ +

+ A parsing connection is a JDBC , which proxies all commands through the jOOQ parser, transforming the inbound SQL statement (and bind variables) given the entirety of jOOQ's , including , (e.g. formatting SQL or inlining bind variables) and much more. This allows for transparent SQL transformation of the SQL produced by any JDBC client (including JPA!). Here's a simple usage example: +

+ + + +

+ Running the above statement will yield: +

+ + + +
+ +
+ Logging +

jOOQ logs all SQL queries and fetched result sets to its internal DEBUG logger, which is implemented as an . By default, execute logging is activated in the . In order to see any DEBUG log output, put either log4j or slf4j on jOOQ's classpath along with their respective configuration. A sample log4j configuration can be seen here: