From db4004f033a7e30a21ed344035e1f21680a67abe Mon Sep 17 00:00:00 2001
From: Lukas Eder
Date: Sun, 30 Jun 2013 17:40:17 +0200
Subject: [PATCH] Release 3.1.0 - Updated manual
---
.../src/main/resources/manual-3.1.xml | 95 ++++++++++++++++++-
1 file changed, 94 insertions(+), 1 deletion(-)
diff --git a/jOOQ-website/src/main/resources/manual-3.1.xml b/jOOQ-website/src/main/resources/manual-3.1.xml
index 7cdcad82be..416511fa23 100644
--- a/jOOQ-website/src/main/resources/manual-3.1.xml
+++ b/jOOQ-website/src/main/resources/manual-3.1.xml
@@ -1367,6 +1367,7 @@ DSLContext create = DSL.using(connection, dialect);]]>
: The dialect of your database. This may be any of the currently supported database types (see for more details)
: An optional runtime configuration (see for more details)
: An optional reference to a provider class that can provide execute listeners to jOOQ (see for more details)
+ : An optional reference to a provider class that can provide record mappers to jOOQ (see for more details)
Any of these:
@@ -6792,6 +6793,10 @@ create.selectFrom(BOOK)
.fetch(book -> book.getId());
]]>
+
+ Your custom RecordMapper types can be used automatically through jOOQ's , by injecting a into your .
+
+
See also the manual's section about the , which provides similar features
@@ -6805,7 +6810,7 @@ create.selectFrom(BOOK)
Fetching data in records is fine as long as your application is not really layered, or as long as you're still writing code in the DAO layer. But if you have a more advanced application architecture, you may not want to allow for jOOQ artefacts to leak into other layers. You may choose to write POJOs (Plain Old Java Objects) as your primary DTOs (Data Transfer Objects), without any dependencies on jOOQ's types, which may even potentially hold a reference to a , and thus a JDBC . Like Hibernate/JPA, jOOQ allows you to operate with POJOs. Unlike Hibernate/JPA, jOOQ does not "attach" those POJOs or create proxies with any magic in them.
- If you're using jOOQ's , you can configure it to for you, but you're not required to use those generated POJOs. You can use your own.
+ If you're using jOOQ's , you can configure it to for you, but you're not required to use those generated POJOs. You can use your own. See the manual's section about to see how to modify jOOQ's standard POJO mapping behaviour.
Using JPA-annotated POJOs
@@ -6978,6 +6983,56 @@ bookDao.delete(book);]]>
+
+
+ POJOs with RecordMappers
+
+
+ In the previous sections we have seen how to create types to map jOOQ records onto arbitrary objects. We have also seen how jOOQ provides default algorithms to map jOOQ records onto . Your own custom domain model might be much more complex, but you want to avoid looking up the most appropriate RecordMapper every time you need one. For this, you can provide jOOQ's with your own implementation of the interface. An example is given here:
+
+
+ RecordMapper provide(RecordType rowType, Class extends E> type) {
+
+ // UUID mappers will always try to find the ID column
+ if (type == UUID.class) {
+ return new RecordMapper() {
+ @Override
+ public E map(R record) {
+ return (E) record.getValue("ID");
+ }
+ }
+ }
+
+ // Books might be joined with their authors, create a 1:1 mapping
+ if (type == Book.class) {
+ return new BookMapper();
+ }
+
+ // Fall back to jOOQ's DefaultRecordMapper, which maps records onto
+ // POJOs using reflection.
+ return new DefaultRecordMapperProvider();
+ }
+ }
+ ))
+ .selectFrom(BOOK)
+ .orderBy(BOOK.ID)
+ .fetchInto(UUID.class);]]>
+
+
+ The above is a very simple example showing that you will have complete flexibility in how to override jOOQ's record to POJO mapping mechanisms.
+
+
+
+ If you're looking into a generic, third-party mapping utility, have a look at ModelMapper, or Orika Mapper, which can both be easily integrated with jOOQ.
+
+
+
Lazy fetching
@@ -7482,6 +7537,44 @@ finally {
ResultQuery maxRows(int rows);
}]]>
+
+ Using ResultSet concurrency with ExecuteListeners
+
+ An example of why you might want to manually set a ResultSet's concurrency flag to something non-default is given here:
+
+
+
+
+
+ In the above example, your custom is triggered before jOOQ loads a new Record from the JDBC ResultSet. With the concurrency being set to ResultSet.CONCUR_UPDATABLE, you can now modify the database cursor through the standard JDBC ResultSet API.
+