This table in HSQLDB generates compilation errors in generated code:
------------------------------------------------------------
CREATE TABLE t_725_lob_test (
ID int NOT NULL,
LOB LONGVARBINARY NULL,
CONSTRAINT pk_t_725_lob_test PRIMARY KEY (id)
)
/
------------------------------------------------------------
Output:
------------------------------------------------------------
/**
* LOB mapping for LOB
*/
public final TableField<T725LobTestRecord, java.lang.Integer> LOB = createField("LOB", org.jooq.impl.SQLDataType.VARBINARY, this);
------------------------------------------------------------
VARBINARY should be recognised as byte[]. I.e. adapt JooqUtils as such:
------------------------------------------------------------
public static String getJooqColumnFullType(Column column) {
String type = column.getType();
if (ConvertUtils.DB_BLOB.equals(type) ||
ConvertUtils.DB_LONGVARBINARY.equals(type) ||
ConvertUtils.DB_LONGBLOB.equals(type)) ||
// Additional check here:
"VARBINARY".equals(type)
return "byte[]";
return CommonUtils.getFullType2(column);
}
------------------------------------------------------------
Note that the behaviour is not consistent. Take this table for instance:
------------------------------------------------------------
CREATE TABLE t_book (
ID INT,
AUTHOR_ID INT NOT NULL,
co_author_id int,
DETAILS_ID INT,
TITLE VARCHAR(400) NOT NULL,
PUBLISHED_IN INT NOT NULL,
LANGUAGE_ID INT NOT NULL,
CONTENT_TEXT LONGVARCHAR,
CONTENT_PDF LONGVARBINARY,
CONSTRAINT pk_t_book PRIMARY KEY (ID)
);
------------------------------------------------------------
CONTENT_PDF looks quite similar, but instead of java.lang.Integer as in the other example, it renders java.lang.String for $jooqColumnFullType:
------------------------------------------------------------
/**
* CONTENT_PDF mapping for CONTENT_PDF
*/
public final TableField<TBookRecord, java.lang.String> CONTENT_PDF = createField("CONTENT_PDF", org.jooq.impl.SQLDataType.VARBINARY, this);
------------------------------------------------------------