From c6468b0a79dadb0130a5531c71e0db450d8b7827 Mon Sep 17 00:00:00 2001 From: Lukas Eder Date: Sun, 30 Jun 2013 16:33:07 +0200 Subject: [PATCH] Release 3.1.0 - Some documentation --- .../src/main/resources/manual-3.1.xml | 80 +++++++++++++++++++ 1 file changed, 80 insertions(+) diff --git a/jOOQ-website/src/main/resources/manual-3.1.xml b/jOOQ-website/src/main/resources/manual-3.1.xml index d889011b70..7cdcad82be 100644 --- a/jOOQ-website/src/main/resources/manual-3.1.xml +++ b/jOOQ-website/src/main/resources/manual-3.1.xml @@ -1458,6 +1458,25 @@ SelectSelectStep select(Field... fields);]]> +
+ SQL Dialect Family + +

+ In jOOQ 3.1, the notion of a SQLDialect.family() was introduced, in order to group several similar into a common family. An example for this is SQL Server, which is supported by jOOQ in various versions: +

+ +
    +
  • : The "version-less" SQL Server version. This always maps to the latest supported version of SQL Server
  • +
  • : The SQL Server version 2012
  • +
  • : The SQL Server version 2008
  • +
+ +

+ In the above list, SQLSERVER is both a dialect and a family of three dialects. This distinction is used internally by jOOQ to distinguish whether to use the clause (SQL Server 2012), or whether to simulate it using ROW_NUMBER() OVER() (SQL Server 2008). +

+
+
+
Connection vs. DataSource @@ -3915,6 +3934,26 @@ public class DSL {
+
+ Datatype coercions + +

+ A slightly different use case than are data type coercions, which are not rendered through to generated SQL. Sometimes, you may want to pretend that a numeric value is really treated as a string value, for instance when binding a numeric : +

+ + field1 = val(1).coerce(String.class); +Field field2 = val("1").coerce(Integer.class);]]> + +

+ In the above example, field1 will be treated by jOOQ as a Field<String>, binding the numeric literal 1 as a VARCHAR value. The same applies to field2, whose string literal "1" will be bound as an INTEGER value. +

+ +

+ This technique is better than performing unsafe or rawtype casting in Java, if you cannot access the "right" field type from any given expression. +

+
+
+
Arithmetic expressions @@ -6437,6 +6476,7 @@ fetch]]>
  • : If you want more fine-grained control over how many records are fetched into memory at once, you can still do that using jOOQ's feature
  • : jOOQ does not formally distinguish between static statements and prepared statements. By default, all statements are prepared statements in jOOQ, internally. Executing a statement as a static statement can be done simply using a
  • : JDBC keeps open resources even if they are already consumed. With JDBC, there is a lot of verbosity around safely closing resources. In jOOQ, resources are closed after consumption, by default. If you want to keep them open after consumption, you have to explicitly say so.
  • +
  • : JDBC execution flags and modes are not modified. They can be set fluently on a
  • @@ -7405,6 +7445,46 @@ finally { +
    + JDBC flags + +

    + JDBC knows a couple of execution flags and modes, which can be set through the jOOQ API as well. jOOQ essentially supports these flags and execution modes: +

    + + + + extends Query { + + // [...] + + // The query execution timeout. + // ----------------------------------------------------------- + @Override + ResultQuery queryTimeout(int timeout); + + // Flags allowing to specify the resulting ResultSet modes + // ----------------------------------------------------------- + ResultQuery resultSetConcurrency(int resultSetConcurrency); + ResultQuery resultSetType(int resultSetType); + ResultQuery resultSetHoldability(int resultSetHoldability); + + // The maximum number of rows to be fetched by JDBC + // ----------------------------------------------------------- + ResultQuery maxRows(int rows); + +}]]> +
    +
    +
    Using JDBC batch operations