In the previous section we have seen how jOOQ's source code generator is configured and run within a few steps. In this chapter we'll cover some advanced settings

<!-- These properties can be added directly to the generator element: -->
<generator>
<!-- The default code generator. You can override this one, to generate your own code style
Defaults to org.jooq.util.JavaGenerator -->
<name>org.jooq.util.JavaGenerator</name>
<!-- The naming strategy used for class and field names.
You may override this with your custom naming strategy. Some examples follow
Defaults to org.jooq.util.DefaultGeneratorStrategy -->
<strategy>
<name>org.jooq.util.DefaultGeneratorStrategy</name>
</strategy>
</generator>

The following example shows how you can override the DefaultGeneratorStrategy to render table and column names the way they are defined in the database, rather than switching them to camel case:

/**
* It is recommended that you extend the DefaultGeneratorStrategy. Most of the
* GeneratorStrategy API is already declared final. You only need to override any
* of the following methods, for whatever generation behaviour you'd like to achieve
*
* Beware that most methods also receive a "Mode" object, to tell you whether a
* TableDefinition is being rendered as a Table, Record, POJO, etc. Depending on
* that information, you can add a suffix only for TableRecords, not for Tables
*/
public class AsInDatabaseStrategy extends DefaultGeneratorStrategy {
/**
* Override this to specifiy what identifiers in Java should look like.
* This will just take the identifier as defined in the database.
*/
@Override
public String getJavaIdentifier(Definition definition) {
return definition.getOutputName();
}
/**
* Override these to specify what a setter in Java should look like. Setters
* are used in TableRecords, UDTRecords, and POJOs. This example will name
* setters "set[NAME_IN_DATABASE]"
*/
@Override
public String getJavaSetterName(Definition definition, Mode mode) {
return "set" + definition.getOutputName();
}
/**
* Just like setters...
*/
@Override
public String getJavaGetterName(Definition definition, Mode mode) {
return "get" + definition.getOutputName();
}
/**
* Override this method to define what a Java method generated from a database
* Definition should look like. This is used mostly for convenience methods
* when calling stored procedures and functions. This example shows how to
* set a prefix to a CamelCase version of your procedure
*/
@Override
public String getJavaMethodName(Definition definition, Mode mode) {
return "call" + org.jooq.tools.StringUtils.toCamelCase(definition.getOutputName());
}
/**
* Override this method to define how your Java classes and Java files should
* be named. This example applies no custom setting and uses CamelCase versions
* instead
*/
@Override
public String getJavaClassName(Definition definition, Mode mode) {
return super.getJavaClassName(definition, mode);
}
/**
* Override this method to re-define the package names of your generated
* artefacts.
*/
@Override
public String getJavaPackageName(Definition definition, Mode mode) {
return super.getJavaPackageName(definition, mode);
}
/**
* Override this method to define how Java members should be named. This is
* used for POJOs and method arguments
*/
@Override
public String getJavaMemberName(Definition definition, Mode mode) {
return definition.getOutputName();
}
/**
* Override this method to define the base class for those artefacts that
* allow for custom base classes
*/
@Override
public String getJavaClassExtends(Definition definition, Mode mode) {
return Object.class.getName();
}
/**
* Override this method to define the interfaces to be implemented by those
* artefacts that allow for custom interface implementation
*/
@Override
public List<String> getJavaClassImplements(Definition definition, Mode mode) {
return Arrays.asList(Serializable.class.getName(), Cloneable.class.getName());
}
/**
* Override this method to define the suffix to apply to routines when
* they are overloaded.
*
* Use this to resolve compile-time conflicts in generated source code, in
* case you make heavy use of procedure overloading
*/
@Override
public String getOverloadSuffix(Definition definition, Mode mode, String overloadIndex) {
return "_OverloadIndex_" + overloadIndex;
}
}

Within the <generator/> element, there are other configuration elements:

<!-- These properties can be added to the database element: -->
<database>
<!-- All table and view columns that are used as "version" fields for
optimistic locking (A Java regular expression. Use the pipe to separate several expressions).
See UpdatableRecord.store() and UpdatableRecord.delete() for details -->
<recordVersionFields>REC_VERSION</recordVersionFields>
<!-- All table and view columns that are used as "timestamp" fields for
optimistic locking (A Java regular expression. Use the pipe to separate several expressions).
See UpdatableRecord.store() and UpdatableRecord.delete() for details -->
<recordTimestampFields>REC_TIMESTAMP</recordTimestampFields>
<!-- Generate java.sql.Timestamp fields for DATE columns. This is
particularly useful for Oracle databases.
Defaults to false -->
<dateAsTimestamp>false</dateAsTimestamp>
<!-- Generate jOOU data types for your unsigned data types, which are
not natively supported in Java.
Defaults to true -->
<unsignedTypes>true</unsignedTypes>
<!-- The schema that is used in generated source code. This will be the
production schema. Use this to override your local development
schema name for source code generation. If not specified, this
will be the same as the input-schema. -->
<outputSchema>[your database schema / owner / name]</outputSchema>
<!-- A configuration element to configure several input and/or output
schemata for jooq-meta, in case you're using jooq-meta in a multi-
schema environment.
This cannot be combined with the above inputSchema / outputSchema -->
<schemata>
<schema>
<inputSchema>...</inputSchema>
<outputSchema>...</outputSchema>
</schema>
[ <schema>...</schema> ... ]
</schemata>
<!-- A configuration element to configure custom data types -->
<customTypes>...</customTypes>
<!-- A configuration element to configure type overrides for generated
artefacts (e.g. in combination with customTypes) -->
<forcedTypes>...</forcedTypes>
</database>

Check out the some of the manual's "advanced" sections to find out more about the advanced configuration parameters.

Also, you can add some optional advanced configuration parameters for the generator:

<!-- These properties can be added to the generate element: -->
<generate>
<!-- Primary key / foreign key relations should be generated and used.
This is a prerequisite for various advanced features.
Defaults to true -->
<relations>true</relations>
<!-- Generate deprecated code for backwards compatibility
Defaults to true -->
<deprecated>true</deprecated>
<!-- Generate instance fields in your tables, as opposed to static
fields. This simplifies aliasing.
Defaults to true -->
<instanceFields>true</instanceFields>
<!-- Generate the javax.annotation.Generated annotation to indicate
jOOQ version used for source code.
Defaults to true -->
<generatedAnnotation>true</generatedAnnotation>
<!-- Generate jOOQ Record classes for type-safe querying. You can
turn this off, if you don't need "active records" for CRUD
Defaults to true -->
<records>true</records>
<!-- Generate POJOs in addition to Record classes for usage of the
ResultQuery.fetchInto(Class) API
Defaults to false -->
<pojos>false</pojos>
<!-- Generate immutable POJOs for usage of the ResultQuery.fetchInto(Class) API
This overrides any value set in <pojos/>
Defaults to false -->
<immutablePojos>false</immutablePojos>
<!-- Generate interfaces that will be implemented by records and/or pojos.
You can also use these interfaces in Record.into(Class<?>) and similar
methods, to let jOOQ return proxy objects for them.
Defaults to false -->
<interfaces>false</interfaces>
<!-- Generate DAOs in addition to POJO classes
Defaults to false -->
<daos>false</daos>
<!-- Annotate POJOs and Records with JPA annotations for increased
compatibility and better integration with JPA/Hibernate, etc
Defaults to false -->
<jpaAnnotations>false</jpaAnnotations>
<!-- Annotate POJOs and Records with JSR-303 validation annotations
Defaults to false -->
<validationAnnotations>false</validationAnnotations>
<!-- Allow to turn off the generation of global object references, which include
- Tables.java
- Sequences.java
- UDTs.java
Turning off the generation of the above files may be necessary for very
large schemas, which exceed the amount of allowed constants in a class's
constant pool (64k) or, whose static initialiser would exceed 64k of
byte code
Defaults to true -->
<globalObjectReferences>true</globalObjectReferences>
</generate>

Some of the above properties depend on other properties to work correctly. For instance, when generating immutable pojos, pojos must be generated. jOOQ will enforce such properties even if you tell it otherwise. Here is a list of property interdependencies: