Release 2.0.1 - Manual updated
This commit is contained in:
Lukas Eder
parent
3d214297cc
commit
a900b69b0f
@ -269,6 +269,22 @@
|
||||
<fo:block font-size="11pt" page-break-inside="avoid">
|
||||
<fo:block text-align-last="justify">
|
||||
<fo:inline>
|
||||
<fo:basic-link internal-destination="BindValues">Bind values<fo:leader leader-pattern="dots"/>
|
||||
<fo:page-number-citation ref-id="BindValues"/>
|
||||
</fo:basic-link>
|
||||
</fo:inline>
|
||||
</fo:block>
|
||||
</fo:block>
|
||||
</fo:list-item-body>
|
||||
</fo:list-item>
|
||||
<fo:list-item>
|
||||
<fo:list-item-label>
|
||||
<fo:block font-size="11pt" page-break-inside="avoid">9.</fo:block>
|
||||
</fo:list-item-label>
|
||||
<fo:list-item-body start-indent="body-start()">
|
||||
<fo:block font-size="11pt" page-break-inside="avoid">
|
||||
<fo:block text-align-last="justify">
|
||||
<fo:inline>
|
||||
<fo:basic-link internal-destination="QueryPart">QueryParts and the global architecture<fo:leader leader-pattern="dots"/>
|
||||
<fo:page-number-citation ref-id="QueryPart"/>
|
||||
</fo:basic-link>
|
||||
@ -279,7 +295,7 @@
|
||||
</fo:list-item>
|
||||
<fo:list-item>
|
||||
<fo:list-item-label>
|
||||
<fo:block font-size="11pt" page-break-inside="avoid">9.</fo:block>
|
||||
<fo:block font-size="11pt" page-break-inside="avoid">10.</fo:block>
|
||||
</fo:list-item-label>
|
||||
<fo:list-item-body start-indent="body-start()">
|
||||
<fo:block font-size="11pt" page-break-inside="avoid">
|
||||
@ -295,7 +311,7 @@
|
||||
</fo:list-item>
|
||||
<fo:list-item>
|
||||
<fo:list-item-label>
|
||||
<fo:block font-size="11pt" page-break-inside="avoid">10.</fo:block>
|
||||
<fo:block font-size="11pt" page-break-inside="avoid">11.</fo:block>
|
||||
</fo:list-item-label>
|
||||
<fo:list-item-body start-indent="body-start()">
|
||||
<fo:block font-size="11pt" page-break-inside="avoid">
|
||||
@ -1904,8 +1920,8 @@ d.execute();</fo:block>
|
||||
The point of the standard MERGE statement is to take a TARGET table, and
|
||||
merge (INSERT, UPDATE) data from a SOURCE table into it. DB2, Oracle,
|
||||
SQL Server and Sybase also allow for DELETING some data and for adding
|
||||
many additional clauses. Those non-standard extensions are currently
|
||||
not supported. Here is an example:
|
||||
many additional clauses. With jOOQ 2.0.1, only Oracle's MERGE extensions are supported.
|
||||
Here is an example:
|
||||
</fo:block>
|
||||
|
||||
<fo:table width="100%" table-layout="fixed">
|
||||
@ -1980,84 +1996,237 @@ WHEN NOT MATCHED THEN INSERT (LAST_NAME)
|
||||
sort of result.
|
||||
</fo:block>
|
||||
<fo:block font-family="Georgia" font-size="16pt" padding-top="10pt" padding-bottom="10pt" page-break-after="avoid">The ResultQuery provides many convenience methods</fo:block>
|
||||
<fo:block font-family="Courier" linefeed-treatment="preserve" white-space-collapse="false" white-space-treatment="preserve" font-size="6pt" margin="12pt" padding="4pt" border="2px solid #882222" background-color="#FFEEDD" page-break-inside="avoid">public interface ResultQuery<R extends Record> {
|
||||
<fo:block font-size="11pt">These methods allow for fetching a jOOQ Result or parts of it.</fo:block>
|
||||
|
||||
<fo:block font-family="Courier" linefeed-treatment="preserve" white-space-collapse="false" white-space-treatment="preserve" font-size="6pt" margin="12pt" padding="4pt" border="2px solid #882222" background-color="#FFEEDD" page-break-inside="avoid"><![CDATA[// Fetch the whole result
|
||||
Result<R> fetch();
|
||||
|
||||
// These methods allow for fetching a jOOQ Result
|
||||
// or parts of it.
|
||||
// ----------------------------------------------
|
||||
// Fetch a single field from the result
|
||||
<T> List<T> fetch(Field<T> field);
|
||||
List<?> fetch(int fieldIndex);
|
||||
<T> List<T> fetch(int fieldIndex, Class<? extends T> type);
|
||||
List<?> fetch(String fieldName);
|
||||
<T> List<T> fetch(String fieldName, Class<? extends T> type);
|
||||
|
||||
// Fetch the whole result
|
||||
Result<R> fetch();
|
||||
// Fetch the first Record
|
||||
R fetchAny();
|
||||
|
||||
// Fetch a single field from the result
|
||||
<T> List<T> fetch(Field<T> field);
|
||||
List<?> fetch(int fieldIndex);
|
||||
List<?> fetch(String fieldName);
|
||||
// Fetch exactly one Record
|
||||
R fetchOne();
|
||||
|
||||
// Fetch the first Record
|
||||
R fetchAny();
|
||||
// Fetch a single field of exactly one Record
|
||||
<T> T fetchOne(Field<T> field);
|
||||
Object fetchOne(int fieldIndex);
|
||||
<T> T fetchOne(int fieldIndex, Class<? extends T> type);
|
||||
Object fetchOne(String fieldName);
|
||||
<T> T fetchOne(String fieldName, Class<? extends T> type);]]></fo:block>
|
||||
|
||||
// Fetch exactly one Record
|
||||
R fetchOne();
|
||||
<fo:block font-size="11pt">These methods transform the result into another form, if org.jooq.Result is not optimal</fo:block>
|
||||
|
||||
<fo:block font-family="Courier" linefeed-treatment="preserve" white-space-collapse="false" white-space-treatment="preserve" font-size="6pt" margin="12pt" padding="4pt" border="2px solid #882222" background-color="#FFEEDD" page-break-inside="avoid"><![CDATA[// Fetch the resulting records as Maps
|
||||
List<Map<String, Object>> fetchMaps();
|
||||
Map<String, Object> fetchOneMap();
|
||||
|
||||
// Fetch a single field of exactly one Record
|
||||
<T> T fetchOne(Field<T> field);
|
||||
Object fetchOne(int fieldIndex);
|
||||
Object fetchOne(String fieldName);
|
||||
// Fetch the result as a Map
|
||||
<K> Map<K, R> fetchMap(Field<K> key);
|
||||
<K, V> Map<K, V> fetchMap(Field<K> key, Field<V> value);
|
||||
|
||||
// These methods transform the result into another
|
||||
// form, if org.jooq.Result is not optimal
|
||||
// -----------------------------------------------
|
||||
// Fetch the resulting records as arrays
|
||||
Object[][] fetchArrays();
|
||||
Object[] fetchOneArray();
|
||||
|
||||
// Fetch the resulting records as Maps
|
||||
List<Map<String, Object>> fetchMaps();
|
||||
Map<String, Object> fetchOneMap();
|
||||
// Fetch a single field as an array
|
||||
<T> T[] fetchArray(Field<T> field);
|
||||
Object[] fetchArray(int fieldIndex);
|
||||
<T> T[] fetchArray(int fieldIndex, Class<? extends T> type);
|
||||
Object[] fetchArray(String fieldName);
|
||||
<T> T[] fetchArray(String fieldName, Class<? extends T> type);]]></fo:block>
|
||||
|
||||
// Fetch the result as a Map
|
||||
<K> Map<K, R> fetchMap(Field<K> key);
|
||||
<K, V> Map<K, V> fetchMap(Field<K> key, Field<V> value);
|
||||
<fo:block font-size="11pt">These methods transform the result into a user-defined form, if org.jooq.Result is not optimal</fo:block>
|
||||
|
||||
// Fetch the resulting records as arrays
|
||||
Object[][] fetchArrays();
|
||||
Object[] fetchOneArray();
|
||||
<fo:block font-family="Courier" linefeed-treatment="preserve" white-space-collapse="false" white-space-treatment="preserve" font-size="6pt" margin="12pt" padding="4pt" border="2px solid #882222" background-color="#FFEEDD" page-break-inside="avoid"><![CDATA[// Fetch the resulting records into a custom POJO
|
||||
// type, which may or may not be JPA-annotated
|
||||
<E> List<E> fetchInto(Class<? extends E> type);
|
||||
|
||||
// Fetch a single field as an array
|
||||
<T> T[] fetchArray(Field<T> field);
|
||||
Object[] fetchArray(int fieldIndex);
|
||||
Object[] fetchArray(String fieldName);
|
||||
// Fetch the resulting records into a custom
|
||||
// record handler, similar to how Spring JdbcTemplate's
|
||||
// RowMapper or the Ollin Framework works.
|
||||
<H extends RecordHandler<R>> H fetchInto(H handler);
|
||||
|
||||
// These methods transform the result into a user-
|
||||
// defined form, if org.jooq.Result is not optimal
|
||||
// -----------------------------------------------
|
||||
// These change the behaviour of fetching itself,
|
||||
// especially, when not all data should be
|
||||
// fetched at once
|
||||
// ----------------------------------------------
|
||||
|
||||
// Fetch the resulting records into a custom POJO
|
||||
// type, which may or may not be JPA-annotated
|
||||
<E> List<E> fetchInto(Class<? extends E> type);
|
||||
// Fetch a Cursor for lazy iteration
|
||||
Cursor<R> fetchLazy();
|
||||
|
||||
// Fetch the resulting records into a custom
|
||||
// record handler, similar to how Spring JdbcTemplate's
|
||||
// RowMapper or the Ollin Framework works.
|
||||
<H extends RecordHandler<R>> H fetchInto(H handler);
|
||||
// Fetch data asynchronously and let client code
|
||||
// decide, when the data must be available.
|
||||
// This makes use of the java.util.concurrent API,
|
||||
// Similar to how Avajé Ebean works.
|
||||
FutureResult<R> fetchLater();
|
||||
FutureResult<R> fetchLater(ExecutorService executor);]]></fo:block>
|
||||
<fo:block font-family="Georgia" font-size="18pt" padding-top="12pt" padding-bottom="12pt" page-break-after="avoid" id="BindValues">
|
||||
<fo:marker marker-class-name="section">
|
||||
<fo:block>1.8. Bind values</fo:block>
|
||||
</fo:marker>1.8. Bind values</fo:block>
|
||||
<fo:block font-size="11pt">
|
||||
Variable binding has a great impact on how you design your SQL queries.
|
||||
It will influence your SQL queries' security aspect as well as execution speed.
|
||||
</fo:block>
|
||||
<fo:block font-family="Georgia" font-size="16pt" padding-top="10pt" padding-bottom="10pt" page-break-after="avoid">Bind values</fo:block>
|
||||
<fo:block font-size="11pt">
|
||||
Bind values are used in SQL / JDBC for various reasons. Among the most
|
||||
obvious ones are:
|
||||
</fo:block>
|
||||
<fo:block padding-top="16pt" padding-bottom="16pt" page-break-inside="avoid">
|
||||
<fo:list-block>
|
||||
<fo:list-item>
|
||||
<fo:list-item-label>
|
||||
<fo:block font-size="11pt" page-break-inside="avoid">-</fo:block>
|
||||
</fo:list-item-label>
|
||||
<fo:list-item-body start-indent="body-start()">
|
||||
<fo:block font-size="11pt" page-break-inside="avoid">
|
||||
Protection against SQL injection. Instead of inlining values
|
||||
possibly originating from user input, you bind those values to
|
||||
your prepared statement and let the JDBC driver / database take
|
||||
care of handling security aspects.
|
||||
</fo:block>
|
||||
</fo:list-item-body>
|
||||
</fo:list-item>
|
||||
<fo:list-item>
|
||||
<fo:list-item-label>
|
||||
<fo:block font-size="11pt" page-break-inside="avoid">-</fo:block>
|
||||
</fo:list-item-label>
|
||||
<fo:list-item-body start-indent="body-start()">
|
||||
<fo:block font-size="11pt" page-break-inside="avoid">
|
||||
Increased speed. Advanced databases such as Oracle can keep
|
||||
execution plans of similar queries in a dedicated cache to prevent
|
||||
hard-parsing your query again and again. In many cases, the actual
|
||||
value of a bind variable does not influence the execution plan, hence
|
||||
it can be reused. Preparing a statement will thus be faster
|
||||
</fo:block>
|
||||
</fo:list-item-body>
|
||||
</fo:list-item>
|
||||
<fo:list-item>
|
||||
<fo:list-item-label>
|
||||
<fo:block font-size="11pt" page-break-inside="avoid">-</fo:block>
|
||||
</fo:list-item-label>
|
||||
<fo:list-item-body start-indent="body-start()">
|
||||
<fo:block font-size="11pt" page-break-inside="avoid">
|
||||
On a JDBC level, you can also reuse the SQL string and prepared statement
|
||||
object instead of constructing it again, as you can bind new values to
|
||||
the prepared statement. This is currently not supported by jOOQ, though
|
||||
</fo:block>
|
||||
</fo:list-item-body>
|
||||
</fo:list-item>
|
||||
</fo:list-block>
|
||||
</fo:block>
|
||||
|
||||
<fo:block font-family="Georgia" font-size="16pt" padding-top="10pt" padding-bottom="10pt" page-break-after="avoid">Ways to introduce bind values with jOOQ</fo:block>
|
||||
<fo:block font-size="11pt">
|
||||
Bind values are omni-present in jOOQ. Whenever you create a condition,
|
||||
you're actually also adding a bind value:
|
||||
</fo:block>
|
||||
<fo:block font-family="Courier" linefeed-treatment="preserve" white-space-collapse="false" white-space-treatment="preserve" font-size="6pt" margin="12pt" padding="4pt" border="2px solid #882222" background-color="#FFEEDD" page-break-inside="avoid">// In jOOQ, "Poe" will be the bind value bound to the condition
|
||||
LAST_NAME.equal("Poe");</fo:block>
|
||||
|
||||
// These change the behaviour of fetching itself,
|
||||
// especially, when not all data should be
|
||||
// fetched at once
|
||||
// ----------------------------------------------
|
||||
|
||||
<fo:block font-size="11pt">
|
||||
The above notation is actually convenient way to explicitly create
|
||||
a bind value for "Poe". You could also write this, instead:
|
||||
</fo:block>
|
||||
<fo:block font-family="Courier" linefeed-treatment="preserve" white-space-collapse="false" white-space-treatment="preserve" font-size="6pt" margin="12pt" padding="4pt" border="2px solid #882222" background-color="#FFEEDD" page-break-inside="avoid">// The Factory allows for explicitly creating bind values
|
||||
LAST_NAME.equal(Factory.val("Poe"));
|
||||
|
||||
// Fetch a Cursor for lazy iteration
|
||||
Cursor<R> fetchLazy();
|
||||
// Or, when static importing Factory.val:
|
||||
LAST_NAME.equal(val("Poe"))</fo:block>
|
||||
|
||||
<fo:block font-size="11pt">
|
||||
Once created, bind values are part of the query's syntax tree (see
|
||||
<fo:basic-link font-size="11pt" color="#882222" font-weight="bold" text-shadow="0 1px 2px #666666" internal-destination="QueryPart">the manual's section about jOOQ's architecture</fo:basic-link>
|
||||
for more information about jOOQ's internals),
|
||||
and cannot be modified directly anymore. If you wish to reuse a query and
|
||||
modify bind values between subsequent query executions, you can access them again
|
||||
through the <fo:basic-link font-size="11pt" color="#882222" font-weight="bold" text-shadow="0 1px 2px #666666" external-destination="url('https://github.com/lukaseder/jOOQ/blob/master/jOOQ/src/main/java/org/jooq/Query.java')">org.jooq.Query</fo:basic-link> interface:
|
||||
</fo:block>
|
||||
|
||||
<fo:block font-family="Courier" linefeed-treatment="preserve" white-space-collapse="false" white-space-treatment="preserve" font-size="6pt" margin="12pt" padding="4pt" border="2px solid #882222" background-color="#FFEEDD" page-break-inside="avoid"><![CDATA[// Access the first bind value from a query. Indexes are counted from 1, just as with JDBC
|
||||
Query query = create.select().from(T_AUTHOR).where(LAST_NAME.equal("Poe"));
|
||||
Param<?> param = query.getParam("1");
|
||||
|
||||
// Fetch data asynchronously and let client code
|
||||
// decide, when the data must be available.
|
||||
// This makes use of the java.util.concurrent API,
|
||||
// Similar to how Avajé Ebean works.
|
||||
FutureResult<R> fetchLater();
|
||||
FutureResult<R> fetchLater(ExecutorService executor);
|
||||
}</fo:block>
|
||||
// You could now modify the Query's underlying bind value:
|
||||
if ("Poe".equal(param.getValue())) {
|
||||
param.setConverted("Orwell");
|
||||
}]]></fo:block>
|
||||
|
||||
<fo:block font-size="11pt">
|
||||
The <fo:basic-link font-size="11pt" color="#882222" font-weight="bold" text-shadow="0 1px 2px #666666" external-destination="url('https://github.com/lukaseder/jOOQ/blob/master/jOOQ/src/main/java/org/jooq/Param.java')">org.jooq.Param</fo:basic-link> type can also be named explicitly
|
||||
using the Factory's param() methods:
|
||||
</fo:block>
|
||||
<fo:block font-family="Courier" linefeed-treatment="preserve" white-space-collapse="false" white-space-treatment="preserve" font-size="6pt" margin="12pt" padding="4pt" border="2px solid #882222" background-color="#FFEEDD" page-break-inside="avoid"><![CDATA[// Create a query with a named parameter. You can then use that name for accessing the parameter again
|
||||
Query query1 = create.select().from(T_AUTHOR).where(LAST_NAME.equal(param("lastName", "Poe")));
|
||||
Param<?> param1 = query.getParam("lastName");
|
||||
|
||||
// Or, keep a reference to the typed parameter in order not to lose the <T> type information:
|
||||
Param<String> param2 = param("lastName", "Poe");
|
||||
Query query2 = create.select().from(T_AUTHOR).where(LAST_NAME.equal(param2));
|
||||
|
||||
// You can now change the bind value directly on the Param reference:
|
||||
param2.setValue("Orwell");
|
||||
]]></fo:block>
|
||||
|
||||
<fo:block font-size="11pt">
|
||||
The <fo:basic-link font-size="11pt" color="#882222" font-weight="bold" text-shadow="0 1px 2px #666666" external-destination="url('https://github.com/lukaseder/jOOQ/blob/master/jOOQ/src/main/java/org/jooq/Query.java')">org.jooq.Query</fo:basic-link> interface also allows for
|
||||
setting new bind values directly, without accessing the Param type:
|
||||
</fo:block>
|
||||
|
||||
<fo:block font-family="Courier" linefeed-treatment="preserve" white-space-collapse="false" white-space-treatment="preserve" font-size="6pt" margin="12pt" padding="4pt" border="2px solid #882222" background-color="#FFEEDD" page-break-inside="avoid">Query query1 = create.select().from(T_AUTHOR).where(LAST_NAME.equal("Poe"));
|
||||
query1.bind(1, "Orwell");
|
||||
|
||||
// Or, with named parameters
|
||||
Query query2 = create.select().from(T_AUTHOR).where(LAST_NAME.equal(param("lastName", "Poe")));
|
||||
query2.bind("lastName", "Orwell");</fo:block>
|
||||
|
||||
<fo:block font-size="11pt">
|
||||
NOTE: Should you wish to use jOOQ only as a query builder and execute
|
||||
queries with another tool, such as Spring Data instead, you can also
|
||||
use the Factory's renderNamedParams() method, to actually render named
|
||||
parameter names in generated SQL:
|
||||
</fo:block>
|
||||
|
||||
<fo:table width="100%" table-layout="fixed">
|
||||
<fo:table-column column-width="88mm"/>
|
||||
<fo:table-column column-width="88mm"/>
|
||||
<fo:table-body>
|
||||
<fo:table-row>
|
||||
<fo:table-cell>
|
||||
<fo:block>
|
||||
<fo:block font-family="Courier" linefeed-treatment="preserve" white-space-collapse="false" white-space-treatment="preserve" font-size="6pt" margin="12pt" padding="4pt" border="2px solid #882222" background-color="#FFEEDD" page-break-inside="avoid">-- The named bind variable can be rendered
|
||||
|
||||
SELECT *
|
||||
FROM T_AUTHOR
|
||||
WHERE LAST_NAME = :lastName
|
||||
</fo:block>
|
||||
</fo:block>
|
||||
</fo:table-cell>
|
||||
<fo:table-cell>
|
||||
<fo:block>
|
||||
<fo:block font-family="Courier" linefeed-treatment="preserve" white-space-collapse="false" white-space-treatment="preserve" font-size="6pt" margin="12pt" padding="4pt" border="2px solid #882222" background-color="#FFEEDD" page-break-inside="avoid">create.renderNamedParams(
|
||||
create.select()
|
||||
.from(T_AUTHOR)
|
||||
.where(LAST_NAME.equal(
|
||||
param("lastName", "Poe"))));</fo:block>
|
||||
</fo:block>
|
||||
</fo:table-cell>
|
||||
</fo:table-row>
|
||||
</fo:table-body>
|
||||
</fo:table>
|
||||
<fo:block font-family="Georgia" font-size="18pt" padding-top="12pt" padding-bottom="12pt" page-break-after="avoid" id="QueryPart">
|
||||
<fo:marker marker-class-name="section">
|
||||
<fo:block>1.8. QueryParts and the global architecture</fo:block>
|
||||
</fo:marker>1.8. QueryParts and the global architecture</fo:block>
|
||||
<fo:block>1.9. QueryParts and the global architecture</fo:block>
|
||||
</fo:marker>1.9. QueryParts and the global architecture</fo:block>
|
||||
<fo:block font-size="11pt">When constructing Query objects in jOOQ, everything is
|
||||
considered a QueryPart. The purpose of this quickly becomes clear when
|
||||
checking out the QueryPart API essentials</fo:block>
|
||||
@ -2152,8 +2321,8 @@ public final void toSQL(RenderContext context) {
|
||||
<fo:block font-size="11pt">For more complex examples, please refer to the codebase, directly</fo:block>
|
||||
<fo:block font-family="Georgia" font-size="18pt" padding-top="12pt" padding-bottom="12pt" page-break-after="avoid" id="Serializability">
|
||||
<fo:marker marker-class-name="section">
|
||||
<fo:block>1.9. Serializability of QueryParts and Results</fo:block>
|
||||
</fo:marker>1.9. Serializability of QueryParts and Results</fo:block>
|
||||
<fo:block>1.10. Serializability of QueryParts and Results</fo:block>
|
||||
</fo:marker>1.10. Serializability of QueryParts and Results</fo:block>
|
||||
<fo:block font-size="11pt">Most of the jOOQ API implements the Serializable interface.
|
||||
This helps storing queries and partial queries in files, transferring
|
||||
queries or result data over TCP/IP, etc. </fo:block>
|
||||
@ -2218,8 +2387,8 @@ ConfigurationRegistry.setProvider(provider);</fo:block>
|
||||
</fo:block>
|
||||
<fo:block font-family="Georgia" font-size="18pt" padding-top="12pt" padding-bottom="12pt" page-break-after="avoid" id="Extend">
|
||||
<fo:marker marker-class-name="section">
|
||||
<fo:block>1.10. Extend jOOQ with custom types</fo:block>
|
||||
</fo:marker>1.10. Extend jOOQ with custom types</fo:block>
|
||||
<fo:block>1.11. Extend jOOQ with custom types</fo:block>
|
||||
</fo:marker>1.11. Extend jOOQ with custom types</fo:block>
|
||||
<fo:block font-size="11pt">Maybe jOOQ is missing functionality that you would like to see,
|
||||
or you can't wait for the next release... In this case, you can extend
|
||||
any of the following open jOOQ implementation classes</fo:block>
|
||||
@ -2380,6 +2549,7 @@ generator.database.input-schema=[your database schema / owner / name]
|
||||
|
||||
#All elements that are generated from your schema (several Java regular expressions, separated by comma)
|
||||
#Watch out for case-sensitivity. Depending on your database, this might be important!
|
||||
#You can create case-insensitive regular expressions using this syntax: (?i:expr)
|
||||
generator.database.includes=.*
|
||||
|
||||
#All elements that are excluded from your schema (several Java regular expressions, separated by comma). Excludes match before includes
|
||||
|
||||
Binary file not shown.
@ -111,6 +111,9 @@ function printContent() {
|
||||
<a title="ResultQuery and various ways of fetching data" href="#ResultQuery">ResultQuery and various ways of fetching data</a>
|
||||
</li>
|
||||
<li>
|
||||
<a title="Bind values" href="#BindValues">Bind values</a>
|
||||
</li>
|
||||
<li>
|
||||
<a title="QueryParts and the global architecture" href="#QueryPart">QueryParts and the global architecture</a>
|
||||
</li>
|
||||
<li>
|
||||
@ -1096,8 +1099,8 @@ d.execute();</pre>
|
||||
The point of the standard MERGE statement is to take a TARGET table, and
|
||||
merge (INSERT, UPDATE) data from a SOURCE table into it. DB2, Oracle,
|
||||
SQL Server and Sybase also allow for DELETING some data and for adding
|
||||
many additional clauses. Those non-standard extensions are currently
|
||||
not supported. Here is an example:
|
||||
many additional clauses. With jOOQ 2.0.1, only Oracle's MERGE extensions are supported.
|
||||
Here is an example:
|
||||
</p>
|
||||
|
||||
<table cellspacing="0" cellpadding="0" width="100%">
|
||||
@ -1151,82 +1154,204 @@ WHEN NOT MATCHED THEN INSERT (LAST_NAME)
|
||||
sort of result.
|
||||
</p>
|
||||
<h2>The ResultQuery provides many convenience methods</h2>
|
||||
<pre class="prettyprint lang-java">public interface ResultQuery<R extends Record> {
|
||||
<p>These methods allow for fetching a jOOQ Result or parts of it.</p>
|
||||
|
||||
<pre class="prettyprint lang-java">// Fetch the whole result
|
||||
Result<R> fetch();
|
||||
|
||||
// These methods allow for fetching a jOOQ Result
|
||||
// or parts of it.
|
||||
// ----------------------------------------------
|
||||
// Fetch a single field from the result
|
||||
<T> List<T> fetch(Field<T> field);
|
||||
List<?> fetch(int fieldIndex);
|
||||
<T> List<T> fetch(int fieldIndex, Class<? extends T> type);
|
||||
List<?> fetch(String fieldName);
|
||||
<T> List<T> fetch(String fieldName, Class<? extends T> type);
|
||||
|
||||
// Fetch the whole result
|
||||
Result<R> fetch();
|
||||
// Fetch the first Record
|
||||
R fetchAny();
|
||||
|
||||
// Fetch a single field from the result
|
||||
<T> List<T> fetch(Field<T> field);
|
||||
List<?> fetch(int fieldIndex);
|
||||
List<?> fetch(String fieldName);
|
||||
// Fetch exactly one Record
|
||||
R fetchOne();
|
||||
|
||||
// Fetch the first Record
|
||||
R fetchAny();
|
||||
// Fetch a single field of exactly one Record
|
||||
<T> T fetchOne(Field<T> field);
|
||||
Object fetchOne(int fieldIndex);
|
||||
<T> T fetchOne(int fieldIndex, Class<? extends T> type);
|
||||
Object fetchOne(String fieldName);
|
||||
<T> T fetchOne(String fieldName, Class<? extends T> type);</pre>
|
||||
|
||||
// Fetch exactly one Record
|
||||
R fetchOne();
|
||||
<p>These methods transform the result into another form, if org.jooq.Result is not optimal</p>
|
||||
|
||||
<pre class="prettyprint lang-java">// Fetch the resulting records as Maps
|
||||
List<Map<String, Object>> fetchMaps();
|
||||
Map<String, Object> fetchOneMap();
|
||||
|
||||
// Fetch a single field of exactly one Record
|
||||
<T> T fetchOne(Field<T> field);
|
||||
Object fetchOne(int fieldIndex);
|
||||
Object fetchOne(String fieldName);
|
||||
// Fetch the result as a Map
|
||||
<K> Map<K, R> fetchMap(Field<K> key);
|
||||
<K, V> Map<K, V> fetchMap(Field<K> key, Field<V> value);
|
||||
|
||||
// These methods transform the result into another
|
||||
// form, if org.jooq.Result is not optimal
|
||||
// -----------------------------------------------
|
||||
// Fetch the resulting records as arrays
|
||||
Object[][] fetchArrays();
|
||||
Object[] fetchOneArray();
|
||||
|
||||
// Fetch the resulting records as Maps
|
||||
List<Map<String, Object>> fetchMaps();
|
||||
Map<String, Object> fetchOneMap();
|
||||
// Fetch a single field as an array
|
||||
<T> T[] fetchArray(Field<T> field);
|
||||
Object[] fetchArray(int fieldIndex);
|
||||
<T> T[] fetchArray(int fieldIndex, Class<? extends T> type);
|
||||
Object[] fetchArray(String fieldName);
|
||||
<T> T[] fetchArray(String fieldName, Class<? extends T> type);</pre>
|
||||
|
||||
// Fetch the result as a Map
|
||||
<K> Map<K, R> fetchMap(Field<K> key);
|
||||
<K, V> Map<K, V> fetchMap(Field<K> key, Field<V> value);
|
||||
<p>These methods transform the result into a user-defined form, if org.jooq.Result is not optimal</p>
|
||||
|
||||
// Fetch the resulting records as arrays
|
||||
Object[][] fetchArrays();
|
||||
Object[] fetchOneArray();
|
||||
<pre class="prettyprint lang-java">// Fetch the resulting records into a custom POJO
|
||||
// type, which may or may not be JPA-annotated
|
||||
<E> List<E> fetchInto(Class<? extends E> type);
|
||||
|
||||
// Fetch a single field as an array
|
||||
<T> T[] fetchArray(Field<T> field);
|
||||
Object[] fetchArray(int fieldIndex);
|
||||
Object[] fetchArray(String fieldName);
|
||||
// Fetch the resulting records into a custom
|
||||
// record handler, similar to how Spring JdbcTemplate's
|
||||
// RowMapper or the Ollin Framework works.
|
||||
<H extends RecordHandler<R>> H fetchInto(H handler);
|
||||
|
||||
// These methods transform the result into a user-
|
||||
// defined form, if org.jooq.Result is not optimal
|
||||
// -----------------------------------------------
|
||||
// These change the behaviour of fetching itself,
|
||||
// especially, when not all data should be
|
||||
// fetched at once
|
||||
// ----------------------------------------------
|
||||
|
||||
// Fetch the resulting records into a custom POJO
|
||||
// type, which may or may not be JPA-annotated
|
||||
<E> List<E> fetchInto(Class<? extends E> type);
|
||||
// Fetch a Cursor for lazy iteration
|
||||
Cursor<R> fetchLazy();
|
||||
|
||||
// Fetch the resulting records into a custom
|
||||
// record handler, similar to how Spring JdbcTemplate's
|
||||
// RowMapper or the Ollin Framework works.
|
||||
<H extends RecordHandler<R>> H fetchInto(H handler);
|
||||
// Fetch data asynchronously and let client code
|
||||
// decide, when the data must be available.
|
||||
// This makes use of the java.util.concurrent API,
|
||||
// Similar to how Avajé Ebean works.
|
||||
FutureResult<R> fetchLater();
|
||||
FutureResult<R> fetchLater(ExecutorService executor);</pre>
|
||||
<h1 id="BindValues">
|
||||
<a name="BindValues"></a>1.8. Bind values</h1><p>
|
||||
Variable binding has a great impact on how you design your SQL queries.
|
||||
It will influence your SQL queries' security aspect as well as execution speed.
|
||||
</p>
|
||||
<h2>Bind values</h2>
|
||||
<p>
|
||||
Bind values are used in SQL / JDBC for various reasons. Among the most
|
||||
obvious ones are:
|
||||
</p>
|
||||
<ul>
|
||||
|
||||
<li>
|
||||
Protection against SQL injection. Instead of inlining values
|
||||
possibly originating from user input, you bind those values to
|
||||
your prepared statement and let the JDBC driver / database take
|
||||
care of handling security aspects.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
Increased speed. Advanced databases such as Oracle can keep
|
||||
execution plans of similar queries in a dedicated cache to prevent
|
||||
hard-parsing your query again and again. In many cases, the actual
|
||||
value of a bind variable does not influence the execution plan, hence
|
||||
it can be reused. Preparing a statement will thus be faster
|
||||
</li>
|
||||
|
||||
<li>
|
||||
On a JDBC level, you can also reuse the SQL string and prepared statement
|
||||
object instead of constructing it again, as you can bind new values to
|
||||
the prepared statement. This is currently not supported by jOOQ, though
|
||||
</li>
|
||||
|
||||
</ul>
|
||||
|
||||
<h3>Ways to introduce bind values with jOOQ</h3>
|
||||
<p>
|
||||
Bind values are omni-present in jOOQ. Whenever you create a condition,
|
||||
you're actually also adding a bind value:
|
||||
</p>
|
||||
<pre class="prettyprint lang-java">// In jOOQ, "Poe" will be the bind value bound to the condition
|
||||
LAST_NAME.equal("Poe");</pre>
|
||||
|
||||
// These change the behaviour of fetching itself,
|
||||
// especially, when not all data should be
|
||||
// fetched at once
|
||||
// ----------------------------------------------
|
||||
|
||||
<p>
|
||||
The above notation is actually convenient way to explicitly create
|
||||
a bind value for "Poe". You could also write this, instead:
|
||||
</p>
|
||||
<pre class="prettyprint lang-java">// The Factory allows for explicitly creating bind values
|
||||
LAST_NAME.equal(Factory.val("Poe"));
|
||||
|
||||
// Fetch a Cursor for lazy iteration
|
||||
Cursor<R> fetchLazy();
|
||||
// Or, when static importing Factory.val:
|
||||
LAST_NAME.equal(val("Poe"))</pre>
|
||||
|
||||
<p>
|
||||
Once created, bind values are part of the query's syntax tree (see
|
||||
<a href="#QueryPart" title="jOOQ Manual reference: QueryParts and the global architecture">the manual's section about jOOQ's architecture</a>
|
||||
for more information about jOOQ's internals),
|
||||
and cannot be modified directly anymore. If you wish to reuse a query and
|
||||
modify bind values between subsequent query executions, you can access them again
|
||||
through the <a href="https://github.com/lukaseder/jOOQ/blob/master/jOOQ/src/main/java/org/jooq/Query.java" title="Internal API reference: org.jooq.Query">org.jooq.Query</a> interface:
|
||||
</p>
|
||||
|
||||
<pre class="prettyprint lang-java">// Access the first bind value from a query. Indexes are counted from 1, just as with JDBC
|
||||
Query query = create.select().from(T_AUTHOR).where(LAST_NAME.equal("Poe"));
|
||||
Param<?> param = query.getParam("1");
|
||||
|
||||
// Fetch data asynchronously and let client code
|
||||
// decide, when the data must be available.
|
||||
// This makes use of the java.util.concurrent API,
|
||||
// Similar to how Avajé Ebean works.
|
||||
FutureResult<R> fetchLater();
|
||||
FutureResult<R> fetchLater(ExecutorService executor);
|
||||
// You could now modify the Query's underlying bind value:
|
||||
if ("Poe".equal(param.getValue())) {
|
||||
param.setConverted("Orwell");
|
||||
}</pre>
|
||||
|
||||
<p>
|
||||
The <a href="https://github.com/lukaseder/jOOQ/blob/master/jOOQ/src/main/java/org/jooq/Param.java" title="Internal API reference: org.jooq.Param">org.jooq.Param</a> type can also be named explicitly
|
||||
using the Factory's param() methods:
|
||||
</p>
|
||||
<pre class="prettyprint lang-java">// Create a query with a named parameter. You can then use that name for accessing the parameter again
|
||||
Query query1 = create.select().from(T_AUTHOR).where(LAST_NAME.equal(param("lastName", "Poe")));
|
||||
Param<?> param1 = query.getParam("lastName");
|
||||
|
||||
// Or, keep a reference to the typed parameter in order not to lose the <T> type information:
|
||||
Param<String> param2 = param("lastName", "Poe");
|
||||
Query query2 = create.select().from(T_AUTHOR).where(LAST_NAME.equal(param2));
|
||||
|
||||
// You can now change the bind value directly on the Param reference:
|
||||
param2.setValue("Orwell");
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
The <a href="https://github.com/lukaseder/jOOQ/blob/master/jOOQ/src/main/java/org/jooq/Query.java" title="Internal API reference: org.jooq.Query">org.jooq.Query</a> interface also allows for
|
||||
setting new bind values directly, without accessing the Param type:
|
||||
</p>
|
||||
|
||||
<pre class="prettyprint lang-java">Query query1 = create.select().from(T_AUTHOR).where(LAST_NAME.equal("Poe"));
|
||||
query1.bind(1, "Orwell");
|
||||
|
||||
// Or, with named parameters
|
||||
Query query2 = create.select().from(T_AUTHOR).where(LAST_NAME.equal(param("lastName", "Poe")));
|
||||
query2.bind("lastName", "Orwell");</pre>
|
||||
|
||||
<p>
|
||||
NOTE: Should you wish to use jOOQ only as a query builder and execute
|
||||
queries with another tool, such as Spring Data instead, you can also
|
||||
use the Factory's renderNamedParams() method, to actually render named
|
||||
parameter names in generated SQL:
|
||||
</p>
|
||||
|
||||
<table cellspacing="0" cellpadding="0" width="100%">
|
||||
<tr>
|
||||
<td class="left" width="50%">
|
||||
<pre class="prettyprint lang-sql">-- The named bind variable can be rendered
|
||||
|
||||
SELECT *
|
||||
FROM T_AUTHOR
|
||||
WHERE LAST_NAME = :lastName
|
||||
</pre>
|
||||
</td><td class="right" width="50%">
|
||||
<pre class="prettyprint lang-java">create.renderNamedParams(
|
||||
create.select()
|
||||
.from(T_AUTHOR)
|
||||
.where(LAST_NAME.equal(
|
||||
param("lastName", "Poe"))));</pre>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
<h1 id="QueryPart">
|
||||
<a name="QueryPart"></a>1.8. QueryParts and the global architecture</h1><p>When constructing Query objects in jOOQ, everything is
|
||||
<a name="QueryPart"></a>1.9. QueryParts and the global architecture</h1><p>When constructing Query objects in jOOQ, everything is
|
||||
considered a QueryPart. The purpose of this quickly becomes clear when
|
||||
checking out the QueryPart API essentials</p>
|
||||
<h2>Everything is a QueryPart</h2>
|
||||
@ -1306,7 +1431,7 @@ public final void toSQL(RenderContext context) {
|
||||
</pre>
|
||||
<p>For more complex examples, please refer to the codebase, directly</p>
|
||||
<h1 id="Serializability">
|
||||
<a name="Serializability"></a>1.9. Serializability of QueryParts and Results</h1><p>Most of the jOOQ API implements the Serializable interface.
|
||||
<a name="Serializability"></a>1.10. Serializability of QueryParts and Results</h1><p>Most of the jOOQ API implements the Serializable interface.
|
||||
This helps storing queries and partial queries in files, transferring
|
||||
queries or result data over TCP/IP, etc. </p>
|
||||
<h2>Attaching QueryParts</h2>
|
||||
@ -1357,7 +1482,7 @@ ConfigurationRegistry.setProvider(provider);</pre>
|
||||
|
||||
</ul>
|
||||
<h1 id="Extend">
|
||||
<a name="Extend"></a>1.10. Extend jOOQ with custom types</h1><p>Maybe jOOQ is missing functionality that you would like to see,
|
||||
<a name="Extend"></a>1.11. Extend jOOQ with custom types</h1><p>Maybe jOOQ is missing functionality that you would like to see,
|
||||
or you can't wait for the next release... In this case, you can extend
|
||||
any of the following open jOOQ implementation classes</p>
|
||||
<h2>Write your own QueryPart implementations</h2>
|
||||
@ -1497,6 +1622,7 @@ generator.database.input-schema=[your database schema / owner / name]
|
||||
|
||||
#All elements that are generated from your schema (several Java regular expressions, separated by comma)
|
||||
#Watch out for case-sensitivity. Depending on your database, this might be important!
|
||||
#You can create case-insensitive regular expressions using this syntax: (?i:expr)
|
||||
generator.database.includes=.*
|
||||
|
||||
#All elements that are excluded from your schema (several Java regular expressions, separated by comma). Excludes match before includes
|
||||
|
||||
154
jOOQ-website/manual/JOOQ/BindValues/index.php
Normal file
154
jOOQ-website/manual/JOOQ/BindValues/index.php
Normal file
@ -0,0 +1,154 @@
|
||||
|
||||
<?php
|
||||
// The following content has been XSL transformed from manual.xml using html-pages.xsl
|
||||
// Please do not edit this content manually
|
||||
require '../../../frame.php';
|
||||
function getH1() {
|
||||
return "Bind values";
|
||||
}
|
||||
function getActiveMenu() {
|
||||
return "manual";
|
||||
}
|
||||
function getSlogan() {
|
||||
return "
|
||||
Variable binding has a great impact on how you design your SQL queries.
|
||||
It will influence your SQL queries' security aspect as well as execution speed.
|
||||
";
|
||||
}
|
||||
function printContent() {
|
||||
global $root;
|
||||
?>
|
||||
<table width="100%" border="0" cellspacing="0" cellpadding="0">
|
||||
<tr>
|
||||
<td valign="top" align="left"><a href="<?=$root?>/manual/">The jOOQ User Manual</a> : <a href="<?=$root?>/manual/JOOQ/">jOOQ classes and their usage</a> : <a href="<?=$root?>/manual/JOOQ/BindValues/">Bind values</a></td><td style="white-space: nowrap" valign="top" align="right"><a title="Previous section: ResultQuery and various ways of fetching data" href="<?=$root?>/manual/JOOQ/ResultQuery/">previous</a> : <a title="Next section: QueryParts and the global architecture" href="<?=$root?>/manual/JOOQ/QueryPart/">next</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
<h2>Bind values</h2>
|
||||
<p>
|
||||
Bind values are used in SQL / JDBC for various reasons. Among the most
|
||||
obvious ones are:
|
||||
</p>
|
||||
<ul>
|
||||
|
||||
<li>
|
||||
Protection against SQL injection. Instead of inlining values
|
||||
possibly originating from user input, you bind those values to
|
||||
your prepared statement and let the JDBC driver / database take
|
||||
care of handling security aspects.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
Increased speed. Advanced databases such as Oracle can keep
|
||||
execution plans of similar queries in a dedicated cache to prevent
|
||||
hard-parsing your query again and again. In many cases, the actual
|
||||
value of a bind variable does not influence the execution plan, hence
|
||||
it can be reused. Preparing a statement will thus be faster
|
||||
</li>
|
||||
|
||||
<li>
|
||||
On a JDBC level, you can also reuse the SQL string and prepared statement
|
||||
object instead of constructing it again, as you can bind new values to
|
||||
the prepared statement. This is currently not supported by jOOQ, though
|
||||
</li>
|
||||
|
||||
</ul>
|
||||
|
||||
<h3>Ways to introduce bind values with jOOQ</h3>
|
||||
<p>
|
||||
Bind values are omni-present in jOOQ. Whenever you create a condition,
|
||||
you're actually also adding a bind value:
|
||||
</p>
|
||||
<pre class="prettyprint lang-java">// In jOOQ, "Poe" will be the bind value bound to the condition
|
||||
LAST_NAME.equal("Poe");</pre>
|
||||
|
||||
|
||||
<p>
|
||||
The above notation is actually convenient way to explicitly create
|
||||
a bind value for "Poe". You could also write this, instead:
|
||||
</p>
|
||||
<pre class="prettyprint lang-java">// The Factory allows for explicitly creating bind values
|
||||
LAST_NAME.equal(Factory.val("Poe"));
|
||||
|
||||
// Or, when static importing Factory.val:
|
||||
LAST_NAME.equal(val("Poe"))</pre>
|
||||
|
||||
<p>
|
||||
Once created, bind values are part of the query's syntax tree (see
|
||||
<a href="<?=$root?>/manual/JOOQ/QueryPart/" title="jOOQ Manual reference: QueryParts and the global architecture">the manual's section about jOOQ's architecture</a>
|
||||
for more information about jOOQ's internals),
|
||||
and cannot be modified directly anymore. If you wish to reuse a query and
|
||||
modify bind values between subsequent query executions, you can access them again
|
||||
through the <a href="https://github.com/lukaseder/jOOQ/blob/master/jOOQ/src/main/java/org/jooq/Query.java" title="Internal API reference: org.jooq.Query">org.jooq.Query</a> interface:
|
||||
</p>
|
||||
|
||||
<pre class="prettyprint lang-java">// Access the first bind value from a query. Indexes are counted from 1, just as with JDBC
|
||||
Query query = create.select().from(T_AUTHOR).where(LAST_NAME.equal("Poe"));
|
||||
Param<?> param = query.getParam("1");
|
||||
|
||||
// You could now modify the Query's underlying bind value:
|
||||
if ("Poe".equal(param.getValue())) {
|
||||
param.setConverted("Orwell");
|
||||
}</pre>
|
||||
|
||||
<p>
|
||||
The <a href="https://github.com/lukaseder/jOOQ/blob/master/jOOQ/src/main/java/org/jooq/Param.java" title="Internal API reference: org.jooq.Param">org.jooq.Param</a> type can also be named explicitly
|
||||
using the Factory's param() methods:
|
||||
</p>
|
||||
<pre class="prettyprint lang-java">// Create a query with a named parameter. You can then use that name for accessing the parameter again
|
||||
Query query1 = create.select().from(T_AUTHOR).where(LAST_NAME.equal(param("lastName", "Poe")));
|
||||
Param<?> param1 = query.getParam("lastName");
|
||||
|
||||
// Or, keep a reference to the typed parameter in order not to lose the <T> type information:
|
||||
Param<String> param2 = param("lastName", "Poe");
|
||||
Query query2 = create.select().from(T_AUTHOR).where(LAST_NAME.equal(param2));
|
||||
|
||||
// You can now change the bind value directly on the Param reference:
|
||||
param2.setValue("Orwell");
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
The <a href="https://github.com/lukaseder/jOOQ/blob/master/jOOQ/src/main/java/org/jooq/Query.java" title="Internal API reference: org.jooq.Query">org.jooq.Query</a> interface also allows for
|
||||
setting new bind values directly, without accessing the Param type:
|
||||
</p>
|
||||
|
||||
<pre class="prettyprint lang-java">Query query1 = create.select().from(T_AUTHOR).where(LAST_NAME.equal("Poe"));
|
||||
query1.bind(1, "Orwell");
|
||||
|
||||
// Or, with named parameters
|
||||
Query query2 = create.select().from(T_AUTHOR).where(LAST_NAME.equal(param("lastName", "Poe")));
|
||||
query2.bind("lastName", "Orwell");</pre>
|
||||
|
||||
<p>
|
||||
NOTE: Should you wish to use jOOQ only as a query builder and execute
|
||||
queries with another tool, such as Spring Data instead, you can also
|
||||
use the Factory's renderNamedParams() method, to actually render named
|
||||
parameter names in generated SQL:
|
||||
</p>
|
||||
|
||||
<table cellspacing="0" cellpadding="0" width="100%">
|
||||
<tr>
|
||||
<td class="left" width="50%">
|
||||
<pre class="prettyprint lang-sql">-- The named bind variable can be rendered
|
||||
|
||||
SELECT *
|
||||
FROM T_AUTHOR
|
||||
WHERE LAST_NAME = :lastName
|
||||
</pre>
|
||||
</td><td class="right" width="50%">
|
||||
<pre class="prettyprint lang-java">create.renderNamedParams(
|
||||
create.select()
|
||||
.from(T_AUTHOR)
|
||||
.where(LAST_NAME.equal(
|
||||
param("lastName", "Poe"))));</pre>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
<br><table width="100%" border="0" cellspacing="0" cellpadding="0">
|
||||
<tr>
|
||||
<td valign="top" align="left"><a href="<?=$root?>/manual/">The jOOQ User Manual</a> : <a href="<?=$root?>/manual/JOOQ/">jOOQ classes and their usage</a> : <a href="<?=$root?>/manual/JOOQ/BindValues/">Bind values</a></td><td style="white-space: nowrap" valign="top" align="right"><a title="Previous section: ResultQuery and various ways of fetching data" href="<?=$root?>/manual/JOOQ/ResultQuery/">previous</a> : <a title="Next section: QueryParts and the global architecture" href="<?=$root?>/manual/JOOQ/QueryPart/">next</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
<?php
|
||||
}
|
||||
?>
|
||||
|
||||
@ -387,8 +387,8 @@ d.execute();</pre>
|
||||
The point of the standard MERGE statement is to take a TARGET table, and
|
||||
merge (INSERT, UPDATE) data from a SOURCE table into it. DB2, Oracle,
|
||||
SQL Server and Sybase also allow for DELETING some data and for adding
|
||||
many additional clauses. Those non-standard extensions are currently
|
||||
not supported. Here is an example:
|
||||
many additional clauses. With jOOQ 2.0.1, only Oracle's MERGE extensions are supported.
|
||||
Here is an example:
|
||||
</p>
|
||||
|
||||
<table cellspacing="0" cellpadding="0" width="100%">
|
||||
|
||||
@ -19,7 +19,7 @@ function printContent() {
|
||||
?>
|
||||
<table width="100%" border="0" cellspacing="0" cellpadding="0">
|
||||
<tr>
|
||||
<td valign="top" align="left"><a href="<?=$root?>/manual/">The jOOQ User Manual</a> : <a href="<?=$root?>/manual/JOOQ/">jOOQ classes and their usage</a> : <a href="<?=$root?>/manual/JOOQ/QueryPart/">QueryParts and the global architecture</a></td><td style="white-space: nowrap" valign="top" align="right"><a title="Previous section: ResultQuery and various ways of fetching data" href="<?=$root?>/manual/JOOQ/ResultQuery/">previous</a> : <a title="Next section: Serializability of QueryParts and Results" href="<?=$root?>/manual/JOOQ/Serializability/">next</a></td>
|
||||
<td valign="top" align="left"><a href="<?=$root?>/manual/">The jOOQ User Manual</a> : <a href="<?=$root?>/manual/JOOQ/">jOOQ classes and their usage</a> : <a href="<?=$root?>/manual/JOOQ/QueryPart/">QueryParts and the global architecture</a></td><td style="white-space: nowrap" valign="top" align="right"><a title="Previous section: Bind values" href="<?=$root?>/manual/JOOQ/BindValues/">previous</a> : <a title="Next section: Serializability of QueryParts and Results" href="<?=$root?>/manual/JOOQ/Serializability/">next</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
<h2>Everything is a QueryPart</h2>
|
||||
@ -100,7 +100,7 @@ public final void toSQL(RenderContext context) {
|
||||
<p>For more complex examples, please refer to the codebase, directly</p>
|
||||
<br><table width="100%" border="0" cellspacing="0" cellpadding="0">
|
||||
<tr>
|
||||
<td valign="top" align="left"><a href="<?=$root?>/manual/">The jOOQ User Manual</a> : <a href="<?=$root?>/manual/JOOQ/">jOOQ classes and their usage</a> : <a href="<?=$root?>/manual/JOOQ/QueryPart/">QueryParts and the global architecture</a></td><td style="white-space: nowrap" valign="top" align="right"><a title="Previous section: ResultQuery and various ways of fetching data" href="<?=$root?>/manual/JOOQ/ResultQuery/">previous</a> : <a title="Next section: Serializability of QueryParts and Results" href="<?=$root?>/manual/JOOQ/Serializability/">next</a></td>
|
||||
<td valign="top" align="left"><a href="<?=$root?>/manual/">The jOOQ User Manual</a> : <a href="<?=$root?>/manual/JOOQ/">jOOQ classes and their usage</a> : <a href="<?=$root?>/manual/JOOQ/QueryPart/">QueryParts and the global architecture</a></td><td style="white-space: nowrap" valign="top" align="right"><a title="Previous section: Bind values" href="<?=$root?>/manual/JOOQ/BindValues/">previous</a> : <a title="Next section: Serializability of QueryParts and Results" href="<?=$root?>/manual/JOOQ/Serializability/">next</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
<?php
|
||||
|
||||
@ -21,87 +21,84 @@ function printContent() {
|
||||
?>
|
||||
<table width="100%" border="0" cellspacing="0" cellpadding="0">
|
||||
<tr>
|
||||
<td valign="top" align="left"><a href="<?=$root?>/manual/">The jOOQ User Manual</a> : <a href="<?=$root?>/manual/JOOQ/">jOOQ classes and their usage</a> : <a href="<?=$root?>/manual/JOOQ/ResultQuery/">ResultQuery and various ways of fetching data</a></td><td style="white-space: nowrap" valign="top" align="right"><a title="Previous section: The Query and its various subtypes" href="<?=$root?>/manual/JOOQ/Query/">previous</a> : <a title="Next section: QueryParts and the global architecture" href="<?=$root?>/manual/JOOQ/QueryPart/">next</a></td>
|
||||
<td valign="top" align="left"><a href="<?=$root?>/manual/">The jOOQ User Manual</a> : <a href="<?=$root?>/manual/JOOQ/">jOOQ classes and their usage</a> : <a href="<?=$root?>/manual/JOOQ/ResultQuery/">ResultQuery and various ways of fetching data</a></td><td style="white-space: nowrap" valign="top" align="right"><a title="Previous section: The Query and its various subtypes" href="<?=$root?>/manual/JOOQ/Query/">previous</a> : <a title="Next section: Bind values" href="<?=$root?>/manual/JOOQ/BindValues/">next</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
<h2>The ResultQuery provides many convenience methods</h2>
|
||||
<pre class="prettyprint lang-java">public interface ResultQuery<R extends Record> {
|
||||
<p>These methods allow for fetching a jOOQ Result or parts of it.</p>
|
||||
|
||||
<pre class="prettyprint lang-java">// Fetch the whole result
|
||||
Result<R> fetch();
|
||||
|
||||
// These methods allow for fetching a jOOQ Result
|
||||
// or parts of it.
|
||||
// ----------------------------------------------
|
||||
// Fetch a single field from the result
|
||||
<T> List<T> fetch(Field<T> field);
|
||||
List<?> fetch(int fieldIndex);
|
||||
<T> List<T> fetch(int fieldIndex, Class<? extends T> type);
|
||||
List<?> fetch(String fieldName);
|
||||
<T> List<T> fetch(String fieldName, Class<? extends T> type);
|
||||
|
||||
// Fetch the whole result
|
||||
Result<R> fetch();
|
||||
// Fetch the first Record
|
||||
R fetchAny();
|
||||
|
||||
// Fetch a single field from the result
|
||||
<T> List<T> fetch(Field<T> field);
|
||||
List<?> fetch(int fieldIndex);
|
||||
List<?> fetch(String fieldName);
|
||||
// Fetch exactly one Record
|
||||
R fetchOne();
|
||||
|
||||
// Fetch the first Record
|
||||
R fetchAny();
|
||||
// Fetch a single field of exactly one Record
|
||||
<T> T fetchOne(Field<T> field);
|
||||
Object fetchOne(int fieldIndex);
|
||||
<T> T fetchOne(int fieldIndex, Class<? extends T> type);
|
||||
Object fetchOne(String fieldName);
|
||||
<T> T fetchOne(String fieldName, Class<? extends T> type);</pre>
|
||||
|
||||
// Fetch exactly one Record
|
||||
R fetchOne();
|
||||
<p>These methods transform the result into another form, if org.jooq.Result is not optimal</p>
|
||||
|
||||
<pre class="prettyprint lang-java">// Fetch the resulting records as Maps
|
||||
List<Map<String, Object>> fetchMaps();
|
||||
Map<String, Object> fetchOneMap();
|
||||
|
||||
// Fetch a single field of exactly one Record
|
||||
<T> T fetchOne(Field<T> field);
|
||||
Object fetchOne(int fieldIndex);
|
||||
Object fetchOne(String fieldName);
|
||||
// Fetch the result as a Map
|
||||
<K> Map<K, R> fetchMap(Field<K> key);
|
||||
<K, V> Map<K, V> fetchMap(Field<K> key, Field<V> value);
|
||||
|
||||
// These methods transform the result into another
|
||||
// form, if org.jooq.Result is not optimal
|
||||
// -----------------------------------------------
|
||||
// Fetch the resulting records as arrays
|
||||
Object[][] fetchArrays();
|
||||
Object[] fetchOneArray();
|
||||
|
||||
// Fetch the resulting records as Maps
|
||||
List<Map<String, Object>> fetchMaps();
|
||||
Map<String, Object> fetchOneMap();
|
||||
// Fetch a single field as an array
|
||||
<T> T[] fetchArray(Field<T> field);
|
||||
Object[] fetchArray(int fieldIndex);
|
||||
<T> T[] fetchArray(int fieldIndex, Class<? extends T> type);
|
||||
Object[] fetchArray(String fieldName);
|
||||
<T> T[] fetchArray(String fieldName, Class<? extends T> type);</pre>
|
||||
|
||||
// Fetch the result as a Map
|
||||
<K> Map<K, R> fetchMap(Field<K> key);
|
||||
<K, V> Map<K, V> fetchMap(Field<K> key, Field<V> value);
|
||||
<p>These methods transform the result into a user-defined form, if org.jooq.Result is not optimal</p>
|
||||
|
||||
// Fetch the resulting records as arrays
|
||||
Object[][] fetchArrays();
|
||||
Object[] fetchOneArray();
|
||||
<pre class="prettyprint lang-java">// Fetch the resulting records into a custom POJO
|
||||
// type, which may or may not be JPA-annotated
|
||||
<E> List<E> fetchInto(Class<? extends E> type);
|
||||
|
||||
// Fetch a single field as an array
|
||||
<T> T[] fetchArray(Field<T> field);
|
||||
Object[] fetchArray(int fieldIndex);
|
||||
Object[] fetchArray(String fieldName);
|
||||
// Fetch the resulting records into a custom
|
||||
// record handler, similar to how Spring JdbcTemplate's
|
||||
// RowMapper or the Ollin Framework works.
|
||||
<H extends RecordHandler<R>> H fetchInto(H handler);
|
||||
|
||||
// These methods transform the result into a user-
|
||||
// defined form, if org.jooq.Result is not optimal
|
||||
// -----------------------------------------------
|
||||
// These change the behaviour of fetching itself,
|
||||
// especially, when not all data should be
|
||||
// fetched at once
|
||||
// ----------------------------------------------
|
||||
|
||||
// Fetch the resulting records into a custom POJO
|
||||
// type, which may or may not be JPA-annotated
|
||||
<E> List<E> fetchInto(Class<? extends E> type);
|
||||
// Fetch a Cursor for lazy iteration
|
||||
Cursor<R> fetchLazy();
|
||||
|
||||
// Fetch the resulting records into a custom
|
||||
// record handler, similar to how Spring JdbcTemplate's
|
||||
// RowMapper or the Ollin Framework works.
|
||||
<H extends RecordHandler<R>> H fetchInto(H handler);
|
||||
|
||||
// These change the behaviour of fetching itself,
|
||||
// especially, when not all data should be
|
||||
// fetched at once
|
||||
// ----------------------------------------------
|
||||
|
||||
// Fetch a Cursor for lazy iteration
|
||||
Cursor<R> fetchLazy();
|
||||
|
||||
// Fetch data asynchronously and let client code
|
||||
// decide, when the data must be available.
|
||||
// This makes use of the java.util.concurrent API,
|
||||
// Similar to how Avajé Ebean works.
|
||||
FutureResult<R> fetchLater();
|
||||
FutureResult<R> fetchLater(ExecutorService executor);
|
||||
}</pre>
|
||||
// Fetch data asynchronously and let client code
|
||||
// decide, when the data must be available.
|
||||
// This makes use of the java.util.concurrent API,
|
||||
// Similar to how Avajé Ebean works.
|
||||
FutureResult<R> fetchLater();
|
||||
FutureResult<R> fetchLater(ExecutorService executor);</pre>
|
||||
<br><table width="100%" border="0" cellspacing="0" cellpadding="0">
|
||||
<tr>
|
||||
<td valign="top" align="left"><a href="<?=$root?>/manual/">The jOOQ User Manual</a> : <a href="<?=$root?>/manual/JOOQ/">jOOQ classes and their usage</a> : <a href="<?=$root?>/manual/JOOQ/ResultQuery/">ResultQuery and various ways of fetching data</a></td><td style="white-space: nowrap" valign="top" align="right"><a title="Previous section: The Query and its various subtypes" href="<?=$root?>/manual/JOOQ/Query/">previous</a> : <a title="Next section: QueryParts and the global architecture" href="<?=$root?>/manual/JOOQ/QueryPart/">next</a></td>
|
||||
<td valign="top" align="left"><a href="<?=$root?>/manual/">The jOOQ User Manual</a> : <a href="<?=$root?>/manual/JOOQ/">jOOQ classes and their usage</a> : <a href="<?=$root?>/manual/JOOQ/ResultQuery/">ResultQuery and various ways of fetching data</a></td><td style="white-space: nowrap" valign="top" align="right"><a title="Previous section: The Query and its various subtypes" href="<?=$root?>/manual/JOOQ/Query/">previous</a> : <a title="Next section: Bind values" href="<?=$root?>/manual/JOOQ/BindValues/">next</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
<?php
|
||||
|
||||
@ -69,6 +69,9 @@ function printContent() {
|
||||
<a title="ResultQuery and various ways of fetching data" href="<?=$root?>/manual/JOOQ/ResultQuery/">ResultQuery and various ways of fetching data</a>
|
||||
</li>
|
||||
<li>
|
||||
<a title="Bind values" href="<?=$root?>/manual/JOOQ/BindValues/">Bind values</a>
|
||||
</li>
|
||||
<li>
|
||||
<a title="QueryParts and the global architecture" href="<?=$root?>/manual/JOOQ/QueryPart/">QueryParts and the global architecture</a>
|
||||
</li>
|
||||
<li>
|
||||
|
||||
@ -94,6 +94,7 @@ generator.database.input-schema=[your database schema / owner / name]
|
||||
|
||||
#All elements that are generated from your schema (several Java regular expressions, separated by comma)
|
||||
#Watch out for case-sensitivity. Depending on your database, this might be important!
|
||||
#You can create case-insensitive regular expressions using this syntax: (?i:expr)
|
||||
generator.database.includes=.*
|
||||
|
||||
#All elements that are excluded from your schema (several Java regular expressions, separated by comma). Excludes match before includes
|
||||
|
||||
@ -117,6 +117,9 @@ function printContent() {
|
||||
<a title="ResultQuery and various ways of fetching data" href="<?=$root?>/manual/JOOQ/ResultQuery/">ResultQuery and various ways of fetching data</a>
|
||||
</li>
|
||||
<li>
|
||||
<a title="Bind values" href="<?=$root?>/manual/JOOQ/BindValues/">Bind values</a>
|
||||
</li>
|
||||
<li>
|
||||
<a title="QueryParts and the global architecture" href="<?=$root?>/manual/JOOQ/QueryPart/">QueryParts and the global architecture</a>
|
||||
</li>
|
||||
<li>
|
||||
|
||||
@ -900,8 +900,8 @@ d.execute();</java>
|
||||
The point of the standard MERGE statement is to take a TARGET table, and
|
||||
merge (INSERT, UPDATE) data from a SOURCE table into it. DB2, Oracle,
|
||||
SQL Server and Sybase also allow for DELETING some data and for adding
|
||||
many additional clauses. Those non-standard extensions are currently
|
||||
not supported. Here is an example:
|
||||
many additional clauses. With jOOQ 2.0.1, only Oracle's MERGE extensions are supported.
|
||||
Here is an example:
|
||||
</p>
|
||||
|
||||
<code-pair>
|
||||
@ -951,80 +951,199 @@ WHEN NOT MATCHED THEN INSERT (LAST_NAME)
|
||||
</slogan>
|
||||
<content>
|
||||
<h2>The ResultQuery provides many convenience methods</h2>
|
||||
<java>public interface ResultQuery<R extends Record> {
|
||||
<p>These methods allow for fetching a jOOQ Result or parts of it.</p>
|
||||
|
||||
<java><![CDATA[// Fetch the whole result
|
||||
Result<R> fetch();
|
||||
|
||||
// These methods allow for fetching a jOOQ Result
|
||||
// or parts of it.
|
||||
// ----------------------------------------------
|
||||
// Fetch a single field from the result
|
||||
<T> List<T> fetch(Field<T> field);
|
||||
List<?> fetch(int fieldIndex);
|
||||
<T> List<T> fetch(int fieldIndex, Class<? extends T> type);
|
||||
List<?> fetch(String fieldName);
|
||||
<T> List<T> fetch(String fieldName, Class<? extends T> type);
|
||||
|
||||
// Fetch the whole result
|
||||
Result<R> fetch();
|
||||
// Fetch the first Record
|
||||
R fetchAny();
|
||||
|
||||
// Fetch a single field from the result
|
||||
<T> List<T> fetch(Field<T> field);
|
||||
List<?> fetch(int fieldIndex);
|
||||
List<?> fetch(String fieldName);
|
||||
// Fetch exactly one Record
|
||||
R fetchOne();
|
||||
|
||||
// Fetch the first Record
|
||||
R fetchAny();
|
||||
// Fetch a single field of exactly one Record
|
||||
<T> T fetchOne(Field<T> field);
|
||||
Object fetchOne(int fieldIndex);
|
||||
<T> T fetchOne(int fieldIndex, Class<? extends T> type);
|
||||
Object fetchOne(String fieldName);
|
||||
<T> T fetchOne(String fieldName, Class<? extends T> type);]]></java>
|
||||
|
||||
// Fetch exactly one Record
|
||||
R fetchOne();
|
||||
<p>These methods transform the result into another form, if org.jooq.Result is not optimal</p>
|
||||
|
||||
<java><![CDATA[// Fetch the resulting records as Maps
|
||||
List<Map<String, Object>> fetchMaps();
|
||||
Map<String, Object> fetchOneMap();
|
||||
|
||||
// Fetch a single field of exactly one Record
|
||||
<T> T fetchOne(Field<T> field);
|
||||
Object fetchOne(int fieldIndex);
|
||||
Object fetchOne(String fieldName);
|
||||
// Fetch the result as a Map
|
||||
<K> Map<K, R> fetchMap(Field<K> key);
|
||||
<K, V> Map<K, V> fetchMap(Field<K> key, Field<V> value);
|
||||
|
||||
// These methods transform the result into another
|
||||
// form, if org.jooq.Result is not optimal
|
||||
// -----------------------------------------------
|
||||
// Fetch the resulting records as arrays
|
||||
Object[][] fetchArrays();
|
||||
Object[] fetchOneArray();
|
||||
|
||||
// Fetch the resulting records as Maps
|
||||
List<Map<String, Object>> fetchMaps();
|
||||
Map<String, Object> fetchOneMap();
|
||||
// Fetch a single field as an array
|
||||
<T> T[] fetchArray(Field<T> field);
|
||||
Object[] fetchArray(int fieldIndex);
|
||||
<T> T[] fetchArray(int fieldIndex, Class<? extends T> type);
|
||||
Object[] fetchArray(String fieldName);
|
||||
<T> T[] fetchArray(String fieldName, Class<? extends T> type);]]></java>
|
||||
|
||||
// Fetch the result as a Map
|
||||
<K> Map<K, R> fetchMap(Field<K> key);
|
||||
<K, V> Map<K, V> fetchMap(Field<K> key, Field<V> value);
|
||||
<p>These methods transform the result into a user-defined form, if org.jooq.Result is not optimal</p>
|
||||
|
||||
// Fetch the resulting records as arrays
|
||||
Object[][] fetchArrays();
|
||||
Object[] fetchOneArray();
|
||||
<java><![CDATA[// Fetch the resulting records into a custom POJO
|
||||
// type, which may or may not be JPA-annotated
|
||||
<E> List<E> fetchInto(Class<? extends E> type);
|
||||
|
||||
// Fetch a single field as an array
|
||||
<T> T[] fetchArray(Field<T> field);
|
||||
Object[] fetchArray(int fieldIndex);
|
||||
Object[] fetchArray(String fieldName);
|
||||
// Fetch the resulting records into a custom
|
||||
// record handler, similar to how Spring JdbcTemplate's
|
||||
// RowMapper or the Ollin Framework works.
|
||||
<H extends RecordHandler<R>> H fetchInto(H handler);
|
||||
|
||||
// These methods transform the result into a user-
|
||||
// defined form, if org.jooq.Result is not optimal
|
||||
// -----------------------------------------------
|
||||
// These change the behaviour of fetching itself,
|
||||
// especially, when not all data should be
|
||||
// fetched at once
|
||||
// ----------------------------------------------
|
||||
|
||||
// Fetch the resulting records into a custom POJO
|
||||
// type, which may or may not be JPA-annotated
|
||||
<E> List<E> fetchInto(Class<? extends E> type);
|
||||
// Fetch a Cursor for lazy iteration
|
||||
Cursor<R> fetchLazy();
|
||||
|
||||
// Fetch the resulting records into a custom
|
||||
// record handler, similar to how Spring JdbcTemplate's
|
||||
// RowMapper or the Ollin Framework works.
|
||||
<H extends RecordHandler<R>> H fetchInto(H handler);
|
||||
// Fetch data asynchronously and let client code
|
||||
// decide, when the data must be available.
|
||||
// This makes use of the java.util.concurrent API,
|
||||
// Similar to how Avajé Ebean works.
|
||||
FutureResult<R> fetchLater();
|
||||
FutureResult<R> fetchLater(ExecutorService executor);]]></java>
|
||||
</content>
|
||||
</section>
|
||||
|
||||
|
||||
<section id="BindValues">
|
||||
<title>Bind values</title>
|
||||
<slogan>
|
||||
Variable binding has a great impact on how you design your SQL queries.
|
||||
It will influence your SQL queries' security aspect as well as execution speed.
|
||||
</slogan>
|
||||
<content>
|
||||
<h2>Bind values</h2>
|
||||
<p>
|
||||
Bind values are used in SQL / JDBC for various reasons. Among the most
|
||||
obvious ones are:
|
||||
</p>
|
||||
<ul>
|
||||
<li>
|
||||
Protection against SQL injection. Instead of inlining values
|
||||
possibly originating from user input, you bind those values to
|
||||
your prepared statement and let the JDBC driver / database take
|
||||
care of handling security aspects.
|
||||
</li>
|
||||
<li>
|
||||
Increased speed. Advanced databases such as Oracle can keep
|
||||
execution plans of similar queries in a dedicated cache to prevent
|
||||
hard-parsing your query again and again. In many cases, the actual
|
||||
value of a bind variable does not influence the execution plan, hence
|
||||
it can be reused. Preparing a statement will thus be faster
|
||||
</li>
|
||||
<li>
|
||||
On a JDBC level, you can also reuse the SQL string and prepared statement
|
||||
object instead of constructing it again, as you can bind new values to
|
||||
the prepared statement. This is currently not supported by jOOQ, though
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<h3>Ways to introduce bind values with jOOQ</h3>
|
||||
<p>
|
||||
Bind values are omni-present in jOOQ. Whenever you create a condition,
|
||||
you're actually also adding a bind value:
|
||||
</p>
|
||||
<java>// In jOOQ, "Poe" will be the bind value bound to the condition
|
||||
LAST_NAME.equal("Poe");</java>
|
||||
|
||||
// These change the behaviour of fetching itself,
|
||||
// especially, when not all data should be
|
||||
// fetched at once
|
||||
// ----------------------------------------------
|
||||
|
||||
<p>
|
||||
The above notation is actually convenient way to explicitly create
|
||||
a bind value for "Poe". You could also write this, instead:
|
||||
</p>
|
||||
<java>// The Factory allows for explicitly creating bind values
|
||||
LAST_NAME.equal(Factory.val("Poe"));
|
||||
|
||||
// Fetch a Cursor for lazy iteration
|
||||
Cursor<R> fetchLazy();
|
||||
// Or, when static importing Factory.val:
|
||||
LAST_NAME.equal(val("Poe"))</java>
|
||||
|
||||
<p>
|
||||
Once created, bind values are part of the query's syntax tree (see
|
||||
<reference id="QueryPart" title="the manual's section about jOOQ's architecture"/>
|
||||
for more information about jOOQ's internals),
|
||||
and cannot be modified directly anymore. If you wish to reuse a query and
|
||||
modify bind values between subsequent query executions, you can access them again
|
||||
through the <reference class="org.jooq.Query"/> interface:
|
||||
</p>
|
||||
|
||||
<java><![CDATA[// Access the first bind value from a query. Indexes are counted from 1, just as with JDBC
|
||||
Query query = create.select().from(T_AUTHOR).where(LAST_NAME.equal("Poe"));
|
||||
Param<?> param = query.getParam("1");
|
||||
|
||||
// Fetch data asynchronously and let client code
|
||||
// decide, when the data must be available.
|
||||
// This makes use of the java.util.concurrent API,
|
||||
// Similar to how Avajé Ebean works.
|
||||
FutureResult<R> fetchLater();
|
||||
FutureResult<R> fetchLater(ExecutorService executor);
|
||||
}</java>
|
||||
// You could now modify the Query's underlying bind value:
|
||||
if ("Poe".equal(param.getValue())) {
|
||||
param.setConverted("Orwell");
|
||||
}]]></java>
|
||||
|
||||
<p>
|
||||
The <reference class="org.jooq.Param"/> type can also be named explicitly
|
||||
using the Factory's param() methods:
|
||||
</p>
|
||||
<java><![CDATA[// Create a query with a named parameter. You can then use that name for accessing the parameter again
|
||||
Query query1 = create.select().from(T_AUTHOR).where(LAST_NAME.equal(param("lastName", "Poe")));
|
||||
Param<?> param1 = query.getParam("lastName");
|
||||
|
||||
// Or, keep a reference to the typed parameter in order not to lose the <T> type information:
|
||||
Param<String> param2 = param("lastName", "Poe");
|
||||
Query query2 = create.select().from(T_AUTHOR).where(LAST_NAME.equal(param2));
|
||||
|
||||
// You can now change the bind value directly on the Param reference:
|
||||
param2.setValue("Orwell");
|
||||
]]></java>
|
||||
|
||||
<p>
|
||||
The <reference class="org.jooq.Query"/> interface also allows for
|
||||
setting new bind values directly, without accessing the Param type:
|
||||
</p>
|
||||
|
||||
<java>Query query1 = create.select().from(T_AUTHOR).where(LAST_NAME.equal("Poe"));
|
||||
query1.bind(1, "Orwell");
|
||||
|
||||
// Or, with named parameters
|
||||
Query query2 = create.select().from(T_AUTHOR).where(LAST_NAME.equal(param("lastName", "Poe")));
|
||||
query2.bind("lastName", "Orwell");</java>
|
||||
|
||||
<p>
|
||||
NOTE: Should you wish to use jOOQ only as a query builder and execute
|
||||
queries with another tool, such as Spring Data instead, you can also
|
||||
use the Factory's renderNamedParams() method, to actually render named
|
||||
parameter names in generated SQL:
|
||||
</p>
|
||||
|
||||
<code-pair>
|
||||
<java>create.renderNamedParams(
|
||||
create.select()
|
||||
.from(T_AUTHOR)
|
||||
.where(LAST_NAME.equal(
|
||||
param("lastName", "Poe"))));</java>
|
||||
<sql>-- The named bind variable can be rendered
|
||||
|
||||
SELECT *
|
||||
FROM T_AUTHOR
|
||||
WHERE LAST_NAME = :lastName
|
||||
</sql>
|
||||
</code-pair>
|
||||
</content>
|
||||
</section>
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user