From 5ec12489ecc5a7f6e3a9804905915879f33d2655 Mon Sep 17 00:00:00 2001 From: lukaseder Date: Thu, 3 Aug 2017 11:44:05 +0200 Subject: [PATCH] [#6472] DB2 and HSQLDB support this syntax as well --- .../resources/org/jooq/web/manual-2.5.xml | 22 +++---------------- .../resources/org/jooq/web/manual-2.6.xml | 22 +++---------------- .../resources/org/jooq/web/manual-3.0.xml | 22 +++---------------- .../resources/org/jooq/web/manual-3.1.xml | 22 +++---------------- .../resources/org/jooq/web/manual-3.10.xml | 18 +-------------- .../resources/org/jooq/web/manual-3.2.xml | 22 +++---------------- .../resources/org/jooq/web/manual-3.3.xml | 22 +++---------------- .../resources/org/jooq/web/manual-3.4.xml | 22 +++---------------- .../resources/org/jooq/web/manual-3.5.xml | 22 +++---------------- .../resources/org/jooq/web/manual-3.6.xml | 22 +++---------------- .../resources/org/jooq/web/manual-3.7.xml | 22 +++---------------- .../resources/org/jooq/web/manual-3.8.xml | 22 +++---------------- .../resources/org/jooq/web/manual-3.9.xml | 22 +++---------------- .../java/org/jooq/AlterTableAlterStep.java | 4 ++-- 14 files changed, 39 insertions(+), 247 deletions(-) diff --git a/jOOQ-manual/src/main/resources/org/jooq/web/manual-2.5.xml b/jOOQ-manual/src/main/resources/org/jooq/web/manual-2.5.xml index bd9081b293..93f83c7e62 100644 --- a/jOOQ-manual/src/main/resources/org/jooq/web/manual-2.5.xml +++ b/jOOQ-manual/src/main/resources/org/jooq/web/manual-2.5.xml @@ -8221,25 +8221,9 @@ create.selectFrom(AUTHOR)
BLOBs and CLOBs -

- jOOQ aims for hiding all JDBC details from jOOQ client API. Specifically, and are quite "harsh" APIs with a few caveats that may even depend on JDBC driver specifics. -

- -

- Clob and Blob are resources (but not !) with open connections to the database. This makes no sense in an ordinary jOOQ context, when eagerly fetching all the results through fetch() methods. fetchLazy() and fetchStream() might be candidates where Clob and Blob types could make sense as the underlying and are still open while consuming these resources. -

- -

- ByteArrayInputStream and ByteArrayOutputStream on the other hand are two different types which cannot be represented as a single Field<T> type. If either would be chosen as the <T> type, we'd get read-only or write-only fields. So for full lazy streaming support, we'd need another 2-way wrapper type, similar to Clob and Blob. -

- -

- In many cases, streaming binary data isn't really necessary as thebyte[] can be easily kept in memory (and it is done so for further processing anyway, e.g. when working with images), so the extra work might not really be needed. This is particularly true in Oracle, where BLOBs are the only binary types in the absences of a formal (VAR)BINARY type, and CLOBs start at 4000 bytes. -

- -

- Hence, jOOQ currently doesn't explicitly support JDBC BLOB and CLOB data types. If you use any of these data types in your database, jOOQ will map them to byte[] and String instead. In simple cases (small data), this simplification is sufficient. In more sophisticated cases, you may have to bypass jOOQ, in order to deal with these data types and their respective resources. -

+

+ jOOQ currently doesn't explicitly support JDBC BLOB and CLOB data types. If you use any of these data types in your database, jOOQ will map them to byte[] and String instead. In simple cases (small data), this simplification is sufficient. In more sophisticated cases, you may have to bypass jOOQ, in order to deal with these data types and their respective resources. True support for LOBs is on the roadmap, though. +

diff --git a/jOOQ-manual/src/main/resources/org/jooq/web/manual-2.6.xml b/jOOQ-manual/src/main/resources/org/jooq/web/manual-2.6.xml index f131361df6..da319e26da 100644 --- a/jOOQ-manual/src/main/resources/org/jooq/web/manual-2.6.xml +++ b/jOOQ-manual/src/main/resources/org/jooq/web/manual-2.6.xml @@ -8828,25 +8828,9 @@ create.selectFrom(AUTHOR)
BLOBs and CLOBs -

- jOOQ aims for hiding all JDBC details from jOOQ client API. Specifically, and are quite "harsh" APIs with a few caveats that may even depend on JDBC driver specifics. -

- -

- Clob and Blob are resources (but not !) with open connections to the database. This makes no sense in an ordinary jOOQ context, when eagerly fetching all the results through fetch() methods. fetchLazy() and fetchStream() might be candidates where Clob and Blob types could make sense as the underlying and are still open while consuming these resources. -

- -

- ByteArrayInputStream and ByteArrayOutputStream on the other hand are two different types which cannot be represented as a single Field<T> type. If either would be chosen as the <T> type, we'd get read-only or write-only fields. So for full lazy streaming support, we'd need another 2-way wrapper type, similar to Clob and Blob. -

- -

- In many cases, streaming binary data isn't really necessary as thebyte[] can be easily kept in memory (and it is done so for further processing anyway, e.g. when working with images), so the extra work might not really be needed. This is particularly true in Oracle, where BLOBs are the only binary types in the absences of a formal (VAR)BINARY type, and CLOBs start at 4000 bytes. -

- -

- Hence, jOOQ currently doesn't explicitly support JDBC BLOB and CLOB data types. If you use any of these data types in your database, jOOQ will map them to byte[] and String instead. In simple cases (small data), this simplification is sufficient. In more sophisticated cases, you may have to bypass jOOQ, in order to deal with these data types and their respective resources. -

+

+ jOOQ currently doesn't explicitly support JDBC BLOB and CLOB data types. If you use any of these data types in your database, jOOQ will map them to byte[] and String instead. In simple cases (small data), this simplification is sufficient. In more sophisticated cases, you may have to bypass jOOQ, in order to deal with these data types and their respective resources. True support for LOBs is on the roadmap, though. +

diff --git a/jOOQ-manual/src/main/resources/org/jooq/web/manual-3.0.xml b/jOOQ-manual/src/main/resources/org/jooq/web/manual-3.0.xml index dba8fbb702..7605a90207 100644 --- a/jOOQ-manual/src/main/resources/org/jooq/web/manual-3.0.xml +++ b/jOOQ-manual/src/main/resources/org/jooq/web/manual-3.0.xml @@ -10302,25 +10302,9 @@ Result result = create.selectFrom(BOOK).where(BOOK.ID.eq(5)).fetch()
BLOBs and CLOBs -

- jOOQ aims for hiding all JDBC details from jOOQ client API. Specifically, and are quite "harsh" APIs with a few caveats that may even depend on JDBC driver specifics. -

- -

- Clob and Blob are resources (but not !) with open connections to the database. This makes no sense in an ordinary jOOQ context, when eagerly fetching all the results through fetch() methods. fetchLazy() and fetchStream() might be candidates where Clob and Blob types could make sense as the underlying and are still open while consuming these resources. -

- -

- ByteArrayInputStream and ByteArrayOutputStream on the other hand are two different types which cannot be represented as a single Field<T> type. If either would be chosen as the <T> type, we'd get read-only or write-only fields. So for full lazy streaming support, we'd need another 2-way wrapper type, similar to Clob and Blob. -

- -

- In many cases, streaming binary data isn't really necessary as thebyte[] can be easily kept in memory (and it is done so for further processing anyway, e.g. when working with images), so the extra work might not really be needed. This is particularly true in Oracle, where BLOBs are the only binary types in the absences of a formal (VAR)BINARY type, and CLOBs start at 4000 bytes. -

- -

- Hence, jOOQ currently doesn't explicitly support JDBC BLOB and CLOB data types. If you use any of these data types in your database, jOOQ will map them to byte[] and String instead. In simple cases (small data), this simplification is sufficient. In more sophisticated cases, you may have to bypass jOOQ, in order to deal with these data types and their respective resources. -

+

+ jOOQ currently doesn't explicitly support JDBC BLOB and CLOB data types. If you use any of these data types in your database, jOOQ will map them to byte[] and String instead. In simple cases (small data), this simplification is sufficient. In more sophisticated cases, you may have to bypass jOOQ, in order to deal with these data types and their respective resources. True support for LOBs is on the roadmap, though. +

diff --git a/jOOQ-manual/src/main/resources/org/jooq/web/manual-3.1.xml b/jOOQ-manual/src/main/resources/org/jooq/web/manual-3.1.xml index f23997c08d..2f02fe97ba 100644 --- a/jOOQ-manual/src/main/resources/org/jooq/web/manual-3.1.xml +++ b/jOOQ-manual/src/main/resources/org/jooq/web/manual-3.1.xml @@ -10866,25 +10866,9 @@ Result result = create.selectFrom(BOOK).where(BOOK.ID.eq(5)).fetch()
BLOBs and CLOBs -

- jOOQ aims for hiding all JDBC details from jOOQ client API. Specifically, and are quite "harsh" APIs with a few caveats that may even depend on JDBC driver specifics. -

- -

- Clob and Blob are resources (but not !) with open connections to the database. This makes no sense in an ordinary jOOQ context, when eagerly fetching all the results through fetch() methods. fetchLazy() and fetchStream() might be candidates where Clob and Blob types could make sense as the underlying and are still open while consuming these resources. -

- -

- ByteArrayInputStream and ByteArrayOutputStream on the other hand are two different types which cannot be represented as a single Field<T> type. If either would be chosen as the <T> type, we'd get read-only or write-only fields. So for full lazy streaming support, we'd need another 2-way wrapper type, similar to Clob and Blob. -

- -

- In many cases, streaming binary data isn't really necessary as thebyte[] can be easily kept in memory (and it is done so for further processing anyway, e.g. when working with images), so the extra work might not really be needed. This is particularly true in Oracle, where BLOBs are the only binary types in the absences of a formal (VAR)BINARY type, and CLOBs start at 4000 bytes. -

- -

- Hence, jOOQ currently doesn't explicitly support JDBC BLOB and CLOB data types. If you use any of these data types in your database, jOOQ will map them to byte[] and String instead. In simple cases (small data), this simplification is sufficient. In more sophisticated cases, you may have to bypass jOOQ, in order to deal with these data types and their respective resources. -

+

+ jOOQ currently doesn't explicitly support JDBC BLOB and CLOB data types. If you use any of these data types in your database, jOOQ will map them to byte[] and String instead. In simple cases (small data), this simplification is sufficient. In more sophisticated cases, you may have to bypass jOOQ, in order to deal with these data types and their respective resources. True support for LOBs is on the roadmap, though. +

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 ccc4390fd2..8ca7c523c8 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 @@ -18661,23 +18661,7 @@ Result> result = create.select( Actor.ACTOR.FIRST_NAME, BLOBs and CLOBs

- jOOQ aims for hiding all JDBC details from jOOQ client API. Specifically, and are quite "harsh" APIs with a few caveats that may even depend on JDBC driver specifics. -

- -

- Clob and Blob are resources (but not !) with open connections to the database. This makes no sense in an ordinary jOOQ context, when eagerly fetching all the results through fetch() methods. fetchLazy() and fetchStream() might be candidates where Clob and Blob types could make sense as the underlying and are still open while consuming these resources. -

- -

- ByteArrayInputStream and ByteArrayOutputStream on the other hand are two different types which cannot be represented as a single Field<T> type. If either would be chosen as the <T> type, we'd get read-only or write-only fields. So for full lazy streaming support, we'd need another 2-way wrapper type, similar to Clob and Blob. -

- -

- In many cases, streaming binary data isn't really necessary as thebyte[] can be easily kept in memory (and it is done so for further processing anyway, e.g. when working with images), so the extra work might not really be needed. This is particularly true in Oracle, where BLOBs are the only binary types in the absences of a formal (VAR)BINARY type, and CLOBs start at 4000 bytes. -

- -

- Hence, jOOQ currently doesn't explicitly support JDBC BLOB and CLOB data types. If you use any of these data types in your database, jOOQ will map them to byte[] and String instead. In simple cases (small data), this simplification is sufficient. In more sophisticated cases, you may have to bypass jOOQ, in order to deal with these data types and their respective resources. + jOOQ currently doesn't explicitly support JDBC BLOB and CLOB data types. If you use any of these data types in your database, jOOQ will map them to byte[] and String instead. In simple cases (small data), this simplification is sufficient. In more sophisticated cases, you may have to bypass jOOQ, in order to deal with these data types and their respective resources. True support for LOBs is on the roadmap, though.

diff --git a/jOOQ-manual/src/main/resources/org/jooq/web/manual-3.2.xml b/jOOQ-manual/src/main/resources/org/jooq/web/manual-3.2.xml index 21dd2bee99..f9ec2317cf 100644 --- a/jOOQ-manual/src/main/resources/org/jooq/web/manual-3.2.xml +++ b/jOOQ-manual/src/main/resources/org/jooq/web/manual-3.2.xml @@ -11676,25 +11676,9 @@ Result result = create.selectFrom(BOOK).where(BOOK.ID.eq(5)).fetch()
BLOBs and CLOBs -

- jOOQ aims for hiding all JDBC details from jOOQ client API. Specifically, and are quite "harsh" APIs with a few caveats that may even depend on JDBC driver specifics. -

- -

- Clob and Blob are resources (but not !) with open connections to the database. This makes no sense in an ordinary jOOQ context, when eagerly fetching all the results through fetch() methods. fetchLazy() and fetchStream() might be candidates where Clob and Blob types could make sense as the underlying and are still open while consuming these resources. -

- -

- ByteArrayInputStream and ByteArrayOutputStream on the other hand are two different types which cannot be represented as a single Field<T> type. If either would be chosen as the <T> type, we'd get read-only or write-only fields. So for full lazy streaming support, we'd need another 2-way wrapper type, similar to Clob and Blob. -

- -

- In many cases, streaming binary data isn't really necessary as thebyte[] can be easily kept in memory (and it is done so for further processing anyway, e.g. when working with images), so the extra work might not really be needed. This is particularly true in Oracle, where BLOBs are the only binary types in the absences of a formal (VAR)BINARY type, and CLOBs start at 4000 bytes. -

- -

- Hence, jOOQ currently doesn't explicitly support JDBC BLOB and CLOB data types. If you use any of these data types in your database, jOOQ will map them to byte[] and String instead. In simple cases (small data), this simplification is sufficient. In more sophisticated cases, you may have to bypass jOOQ, in order to deal with these data types and their respective resources. -

+

+ jOOQ currently doesn't explicitly support JDBC BLOB and CLOB data types. If you use any of these data types in your database, jOOQ will map them to byte[] and String instead. In simple cases (small data), this simplification is sufficient. In more sophisticated cases, you may have to bypass jOOQ, in order to deal with these data types and their respective resources. True support for LOBs is on the roadmap, though. +

diff --git a/jOOQ-manual/src/main/resources/org/jooq/web/manual-3.3.xml b/jOOQ-manual/src/main/resources/org/jooq/web/manual-3.3.xml index c815ef99b8..81c55e7fe8 100644 --- a/jOOQ-manual/src/main/resources/org/jooq/web/manual-3.3.xml +++ b/jOOQ-manual/src/main/resources/org/jooq/web/manual-3.3.xml @@ -12609,25 +12609,9 @@ Result> result = create.select( Actor.ACTOR.FIRST_NAME,
BLOBs and CLOBs -

- jOOQ aims for hiding all JDBC details from jOOQ client API. Specifically, and are quite "harsh" APIs with a few caveats that may even depend on JDBC driver specifics. -

- -

- Clob and Blob are resources (but not !) with open connections to the database. This makes no sense in an ordinary jOOQ context, when eagerly fetching all the results through fetch() methods. fetchLazy() and fetchStream() might be candidates where Clob and Blob types could make sense as the underlying and are still open while consuming these resources. -

- -

- ByteArrayInputStream and ByteArrayOutputStream on the other hand are two different types which cannot be represented as a single Field<T> type. If either would be chosen as the <T> type, we'd get read-only or write-only fields. So for full lazy streaming support, we'd need another 2-way wrapper type, similar to Clob and Blob. -

- -

- In many cases, streaming binary data isn't really necessary as thebyte[] can be easily kept in memory (and it is done so for further processing anyway, e.g. when working with images), so the extra work might not really be needed. This is particularly true in Oracle, where BLOBs are the only binary types in the absences of a formal (VAR)BINARY type, and CLOBs start at 4000 bytes. -

- -

- Hence, jOOQ currently doesn't explicitly support JDBC BLOB and CLOB data types. If you use any of these data types in your database, jOOQ will map them to byte[] and String instead. In simple cases (small data), this simplification is sufficient. In more sophisticated cases, you may have to bypass jOOQ, in order to deal with these data types and their respective resources. -

+

+ jOOQ currently doesn't explicitly support JDBC BLOB and CLOB data types. If you use any of these data types in your database, jOOQ will map them to byte[] and String instead. In simple cases (small data), this simplification is sufficient. In more sophisticated cases, you may have to bypass jOOQ, in order to deal with these data types and their respective resources. True support for LOBs is on the roadmap, though. +

diff --git a/jOOQ-manual/src/main/resources/org/jooq/web/manual-3.4.xml b/jOOQ-manual/src/main/resources/org/jooq/web/manual-3.4.xml index 857a209d4c..badd198d8d 100644 --- a/jOOQ-manual/src/main/resources/org/jooq/web/manual-3.4.xml +++ b/jOOQ-manual/src/main/resources/org/jooq/web/manual-3.4.xml @@ -13991,25 +13991,9 @@ Result> result = create.select( Actor.ACTOR.FIRST_NAME,
BLOBs and CLOBs -

- jOOQ aims for hiding all JDBC details from jOOQ client API. Specifically, and are quite "harsh" APIs with a few caveats that may even depend on JDBC driver specifics. -

- -

- Clob and Blob are resources (but not !) with open connections to the database. This makes no sense in an ordinary jOOQ context, when eagerly fetching all the results through fetch() methods. fetchLazy() and fetchStream() might be candidates where Clob and Blob types could make sense as the underlying and are still open while consuming these resources. -

- -

- ByteArrayInputStream and ByteArrayOutputStream on the other hand are two different types which cannot be represented as a single Field<T> type. If either would be chosen as the <T> type, we'd get read-only or write-only fields. So for full lazy streaming support, we'd need another 2-way wrapper type, similar to Clob and Blob. -

- -

- In many cases, streaming binary data isn't really necessary as thebyte[] can be easily kept in memory (and it is done so for further processing anyway, e.g. when working with images), so the extra work might not really be needed. This is particularly true in Oracle, where BLOBs are the only binary types in the absences of a formal (VAR)BINARY type, and CLOBs start at 4000 bytes. -

- -

- Hence, jOOQ currently doesn't explicitly support JDBC BLOB and CLOB data types. If you use any of these data types in your database, jOOQ will map them to byte[] and String instead. In simple cases (small data), this simplification is sufficient. In more sophisticated cases, you may have to bypass jOOQ, in order to deal with these data types and their respective resources. -

+

+ jOOQ currently doesn't explicitly support JDBC BLOB and CLOB data types. If you use any of these data types in your database, jOOQ will map them to byte[] and String instead. In simple cases (small data), this simplification is sufficient. In more sophisticated cases, you may have to bypass jOOQ, in order to deal with these data types and their respective resources. True support for LOBs is on the roadmap, though. +

diff --git a/jOOQ-manual/src/main/resources/org/jooq/web/manual-3.5.xml b/jOOQ-manual/src/main/resources/org/jooq/web/manual-3.5.xml index 07609a2fcf..c0df34f3ca 100644 --- a/jOOQ-manual/src/main/resources/org/jooq/web/manual-3.5.xml +++ b/jOOQ-manual/src/main/resources/org/jooq/web/manual-3.5.xml @@ -14699,25 +14699,9 @@ Result> result = create.select( Actor.ACTOR.FIRST_NAME,
BLOBs and CLOBs -

- jOOQ aims for hiding all JDBC details from jOOQ client API. Specifically, and are quite "harsh" APIs with a few caveats that may even depend on JDBC driver specifics. -

- -

- Clob and Blob are resources (but not !) with open connections to the database. This makes no sense in an ordinary jOOQ context, when eagerly fetching all the results through fetch() methods. fetchLazy() and fetchStream() might be candidates where Clob and Blob types could make sense as the underlying and are still open while consuming these resources. -

- -

- ByteArrayInputStream and ByteArrayOutputStream on the other hand are two different types which cannot be represented as a single Field<T> type. If either would be chosen as the <T> type, we'd get read-only or write-only fields. So for full lazy streaming support, we'd need another 2-way wrapper type, similar to Clob and Blob. -

- -

- In many cases, streaming binary data isn't really necessary as thebyte[] can be easily kept in memory (and it is done so for further processing anyway, e.g. when working with images), so the extra work might not really be needed. This is particularly true in Oracle, where BLOBs are the only binary types in the absences of a formal (VAR)BINARY type, and CLOBs start at 4000 bytes. -

- -

- Hence, jOOQ currently doesn't explicitly support JDBC BLOB and CLOB data types. If you use any of these data types in your database, jOOQ will map them to byte[] and String instead. In simple cases (small data), this simplification is sufficient. In more sophisticated cases, you may have to bypass jOOQ, in order to deal with these data types and their respective resources. -

+

+ jOOQ currently doesn't explicitly support JDBC BLOB and CLOB data types. If you use any of these data types in your database, jOOQ will map them to byte[] and String instead. In simple cases (small data), this simplification is sufficient. In more sophisticated cases, you may have to bypass jOOQ, in order to deal with these data types and their respective resources. True support for LOBs is on the roadmap, though. +

diff --git a/jOOQ-manual/src/main/resources/org/jooq/web/manual-3.6.xml b/jOOQ-manual/src/main/resources/org/jooq/web/manual-3.6.xml index c432910e2d..97e5acc8ef 100644 --- a/jOOQ-manual/src/main/resources/org/jooq/web/manual-3.6.xml +++ b/jOOQ-manual/src/main/resources/org/jooq/web/manual-3.6.xml @@ -15735,25 +15735,9 @@ Result> result = create.select( Actor.ACTOR.FIRST_NAME,
BLOBs and CLOBs -

- jOOQ aims for hiding all JDBC details from jOOQ client API. Specifically, and are quite "harsh" APIs with a few caveats that may even depend on JDBC driver specifics. -

- -

- Clob and Blob are resources (but not !) with open connections to the database. This makes no sense in an ordinary jOOQ context, when eagerly fetching all the results through fetch() methods. fetchLazy() and fetchStream() might be candidates where Clob and Blob types could make sense as the underlying and are still open while consuming these resources. -

- -

- ByteArrayInputStream and ByteArrayOutputStream on the other hand are two different types which cannot be represented as a single Field<T> type. If either would be chosen as the <T> type, we'd get read-only or write-only fields. So for full lazy streaming support, we'd need another 2-way wrapper type, similar to Clob and Blob. -

- -

- In many cases, streaming binary data isn't really necessary as thebyte[] can be easily kept in memory (and it is done so for further processing anyway, e.g. when working with images), so the extra work might not really be needed. This is particularly true in Oracle, where BLOBs are the only binary types in the absences of a formal (VAR)BINARY type, and CLOBs start at 4000 bytes. -

- -

- Hence, jOOQ currently doesn't explicitly support JDBC BLOB and CLOB data types. If you use any of these data types in your database, jOOQ will map them to byte[] and String instead. In simple cases (small data), this simplification is sufficient. In more sophisticated cases, you may have to bypass jOOQ, in order to deal with these data types and their respective resources. -

+

+ jOOQ currently doesn't explicitly support JDBC BLOB and CLOB data types. If you use any of these data types in your database, jOOQ will map them to byte[] and String instead. In simple cases (small data), this simplification is sufficient. In more sophisticated cases, you may have to bypass jOOQ, in order to deal with these data types and their respective resources. True support for LOBs is on the roadmap, though. +

diff --git a/jOOQ-manual/src/main/resources/org/jooq/web/manual-3.7.xml b/jOOQ-manual/src/main/resources/org/jooq/web/manual-3.7.xml index 1f4ac9c908..9a41fede98 100644 --- a/jOOQ-manual/src/main/resources/org/jooq/web/manual-3.7.xml +++ b/jOOQ-manual/src/main/resources/org/jooq/web/manual-3.7.xml @@ -16178,25 +16178,9 @@ Result> result = create.select( Actor.ACTOR.FIRST_NAME,
BLOBs and CLOBs -

- jOOQ aims for hiding all JDBC details from jOOQ client API. Specifically, and are quite "harsh" APIs with a few caveats that may even depend on JDBC driver specifics. -

- -

- Clob and Blob are resources (but not !) with open connections to the database. This makes no sense in an ordinary jOOQ context, when eagerly fetching all the results through fetch() methods. fetchLazy() and fetchStream() might be candidates where Clob and Blob types could make sense as the underlying and are still open while consuming these resources. -

- -

- ByteArrayInputStream and ByteArrayOutputStream on the other hand are two different types which cannot be represented as a single Field<T> type. If either would be chosen as the <T> type, we'd get read-only or write-only fields. So for full lazy streaming support, we'd need another 2-way wrapper type, similar to Clob and Blob. -

- -

- In many cases, streaming binary data isn't really necessary as thebyte[] can be easily kept in memory (and it is done so for further processing anyway, e.g. when working with images), so the extra work might not really be needed. This is particularly true in Oracle, where BLOBs are the only binary types in the absences of a formal (VAR)BINARY type, and CLOBs start at 4000 bytes. -

- -

- Hence, jOOQ currently doesn't explicitly support JDBC BLOB and CLOB data types. If you use any of these data types in your database, jOOQ will map them to byte[] and String instead. In simple cases (small data), this simplification is sufficient. In more sophisticated cases, you may have to bypass jOOQ, in order to deal with these data types and their respective resources. -

+

+ jOOQ currently doesn't explicitly support JDBC BLOB and CLOB data types. If you use any of these data types in your database, jOOQ will map them to byte[] and String instead. In simple cases (small data), this simplification is sufficient. In more sophisticated cases, you may have to bypass jOOQ, in order to deal with these data types and their respective resources. True support for LOBs is on the roadmap, though. +

diff --git a/jOOQ-manual/src/main/resources/org/jooq/web/manual-3.8.xml b/jOOQ-manual/src/main/resources/org/jooq/web/manual-3.8.xml index c31182fbf0..3a82aaf049 100644 --- a/jOOQ-manual/src/main/resources/org/jooq/web/manual-3.8.xml +++ b/jOOQ-manual/src/main/resources/org/jooq/web/manual-3.8.xml @@ -16451,25 +16451,9 @@ Result> result = create.select( Actor.ACTOR.FIRST_NAME,
BLOBs and CLOBs -

- jOOQ aims for hiding all JDBC details from jOOQ client API. Specifically, and are quite "harsh" APIs with a few caveats that may even depend on JDBC driver specifics. -

- -

- Clob and Blob are resources (but not !) with open connections to the database. This makes no sense in an ordinary jOOQ context, when eagerly fetching all the results through fetch() methods. fetchLazy() and fetchStream() might be candidates where Clob and Blob types could make sense as the underlying and are still open while consuming these resources. -

- -

- ByteArrayInputStream and ByteArrayOutputStream on the other hand are two different types which cannot be represented as a single Field<T> type. If either would be chosen as the <T> type, we'd get read-only or write-only fields. So for full lazy streaming support, we'd need another 2-way wrapper type, similar to Clob and Blob. -

- -

- In many cases, streaming binary data isn't really necessary as thebyte[] can be easily kept in memory (and it is done so for further processing anyway, e.g. when working with images), so the extra work might not really be needed. This is particularly true in Oracle, where BLOBs are the only binary types in the absences of a formal (VAR)BINARY type, and CLOBs start at 4000 bytes. -

- -

- Hence, jOOQ currently doesn't explicitly support JDBC BLOB and CLOB data types. If you use any of these data types in your database, jOOQ will map them to byte[] and String instead. In simple cases (small data), this simplification is sufficient. In more sophisticated cases, you may have to bypass jOOQ, in order to deal with these data types and their respective resources. -

+

+ jOOQ currently doesn't explicitly support JDBC BLOB and CLOB data types. If you use any of these data types in your database, jOOQ will map them to byte[] and String instead. In simple cases (small data), this simplification is sufficient. In more sophisticated cases, you may have to bypass jOOQ, in order to deal with these data types and their respective resources. True support for LOBs is on the roadmap, though. +

diff --git a/jOOQ-manual/src/main/resources/org/jooq/web/manual-3.9.xml b/jOOQ-manual/src/main/resources/org/jooq/web/manual-3.9.xml index 9b805ccf72..7da75987e5 100644 --- a/jOOQ-manual/src/main/resources/org/jooq/web/manual-3.9.xml +++ b/jOOQ-manual/src/main/resources/org/jooq/web/manual-3.9.xml @@ -18246,25 +18246,9 @@ Result> result = create.select( Actor.ACTOR.FIRST_NAME,
BLOBs and CLOBs -

- jOOQ aims for hiding all JDBC details from jOOQ client API. Specifically, and are quite "harsh" APIs with a few caveats that may even depend on JDBC driver specifics. -

- -

- Clob and Blob are resources (but not !) with open connections to the database. This makes no sense in an ordinary jOOQ context, when eagerly fetching all the results through fetch() methods. fetchLazy() and fetchStream() might be candidates where Clob and Blob types could make sense as the underlying and are still open while consuming these resources. -

- -

- ByteArrayInputStream and ByteArrayOutputStream on the other hand are two different types which cannot be represented as a single Field<T> type. If either would be chosen as the <T> type, we'd get read-only or write-only fields. So for full lazy streaming support, we'd need another 2-way wrapper type, similar to Clob and Blob. -

- -

- In many cases, streaming binary data isn't really necessary as thebyte[] can be easily kept in memory (and it is done so for further processing anyway, e.g. when working with images), so the extra work might not really be needed. This is particularly true in Oracle, where BLOBs are the only binary types in the absences of a formal (VAR)BINARY type, and CLOBs start at 4000 bytes. -

- -

- Hence, jOOQ currently doesn't explicitly support JDBC BLOB and CLOB data types. If you use any of these data types in your database, jOOQ will map them to byte[] and String instead. In simple cases (small data), this simplification is sufficient. In more sophisticated cases, you may have to bypass jOOQ, in order to deal with these data types and their respective resources. -

+

+ jOOQ currently doesn't explicitly support JDBC BLOB and CLOB data types. If you use any of these data types in your database, jOOQ will map them to byte[] and String instead. In simple cases (small data), this simplification is sufficient. In more sophisticated cases, you may have to bypass jOOQ, in order to deal with these data types and their respective resources. True support for LOBs is on the roadmap, though. +

diff --git a/jOOQ/src/main/java/org/jooq/AlterTableAlterStep.java b/jOOQ/src/main/java/org/jooq/AlterTableAlterStep.java index 977b955a8d..47dcb434ef 100644 --- a/jOOQ/src/main/java/org/jooq/AlterTableAlterStep.java +++ b/jOOQ/src/main/java/org/jooq/AlterTableAlterStep.java @@ -84,12 +84,12 @@ public interface AlterTableAlterStep { /** * Make the column NOT NULL. */ - @Support({ H2, POSTGRES }) + @Support({ H2, HSQLDB, POSTGRES }) AlterTableFinalStep setNotNull(); /** * Make the column nullable. */ - @Support({ H2, POSTGRES }) + @Support({ H2, HSQLDB, POSTGRES }) AlterTableFinalStep dropNotNull(); }