Top Description Methods
org.jooq

public Interface LoaderOptionsStep<R extends org.jooq.Record>

extends LoaderSourceStep<R extends Record>
Known Direct Implementers
org.jooq.impl.LoaderImpl
Static Imports
org.jooq.SQLDialect.CUBRID, .SQLDialect.DERBY, .SQLDialect.H2, .SQLDialect.HSQLDB, .SQLDialect.MARIADB, .SQLDialect.MYSQL, .SQLDialect.POSTGRES, .SQLDialect.SQLITE
The Loader API is used for configuring data loads.

Add options to for the loading behaviour. For performance reasons, you can fine-tune three different types of measures:

Referencing XYZ*Step types directly from client code

It is usually not recommended to reference any XYZ*Step types directly from client code, or assign them to local variables. When writing dynamic SQL, creating a statement's components dynamically, and passing them to the DSL API statically is usually a better choice. See the manual's section about dynamic SQL for details: https://www.jooq.org/doc/latest/manual/sql-building/dynamic-sql.

Drawbacks of referencing the XYZ*Step types directly:

Author
Lukas Eder

Method Summary

Modifier and TypeMethod and Description
public @NotNull LoaderOptionsStep<R>
batchAfter(int
The number of records that are batched together.
number)

Batch a given number of bulk statements together.

public @NotNull LoaderOptionsStep<R>
batchAll()

Batch all bulk statements in one JDBC batch statement.

public @NotNull LoaderOptionsStep<R>
batchNone()

Do not batch bulk statements together.

public @NotNull LoaderOptionsStep<R>
bulkAfter(int
The number of records that are put together in one bulk statement.
number)

Bulk-insert a given number of statements in a single multi-row bulk statement.

public @NotNull LoaderOptionsStep<R>
bulkAll()

Bulk-insert all rows in a single multi-row bulk statement.

public @NotNull LoaderOptionsStep<R>
bulkNone()

Do not bulk-insert rows in multi-row bulk statements.

public @NotNull LoaderOptionsStep<R>
commitAfter(int
The number of records that are committed together.
number)

Commit after a certain number of batches.

public @NotNull LoaderOptionsStep<R>
commitAll()

Commit only after inserting all batches.

public @NotNull LoaderOptionsStep<R>
commitEach()

Commit each batch.

public @NotNull LoaderOptionsStep<R>
commitNone()

Leave committing / rollbacking up to client code.

public @NotNull LoaderOptionsStep<R>
onDuplicateKeyError()

Instruct the Loader to cause an error in loading if there are any duplicate records.

public @NotNull LoaderOptionsStep<R>
onDuplicateKeyIgnore()

Instruct the Loader to skip duplicate records if any of the unique keys' values are already in the database.

public @NotNull LoaderOptionsStep<R>
onDuplicateKeyUpdate()

Instruct the Loader to update duplicate records if any of the unique keys' values are already in the database.

public @NotNull LoaderOptionsStep<R>
onErrorAbort()

Instruct the Loader to abort loading after the first error that might occur when inserting a record.

public @NotNull LoaderOptionsStep<R>
onErrorIgnore()

Instruct the Loader to ignore any errors that might occur when inserting a record.

Inherited from org.jooq.LoaderSourceStep:
loadArraysloadArraysloadArraysloadArraysloadCSVloadCSVloadCSVloadCSVloadCSVloadCSVloadCSVloadCSVloadCSVloadCSVloadCSVloadJSONloadJSONloadJSONloadJSONloadJSONloadJSONloadJSONloadJSONloadJSONloadJSONloadJSONloadRecordsloadRecordsloadRecordsloadRecordsloadXMLloadXMLloadXMLloadXMLloadXMLloadXMLloadXMLloadXMLloadXMLloadXMLloadXMLloadXML

Method Detail

batchAfterback to summary
public @NotNull LoaderOptionsStep<R> batchAfter(int number)

Batch a given number of bulk statements together.

Parameters
number:int

The number of records that are batched together.

Annotations
@NotNull
@CheckReturnValue
@Support
batchAllback to summary
public @NotNull LoaderOptionsStep<R> batchAll()

Batch all bulk statements in one JDBC batch statement.

If commitEach() or commitAfter(int) are set, this will force the COMMIT option to commitAll().

Annotations
@NotNull
@CheckReturnValue
@Support
batchNoneback to summary
public @NotNull LoaderOptionsStep<R> batchNone()

Do not batch bulk statements together.

If you don't specify a BATCH OPTION, this will be the default.

Annotations
@NotNull
@CheckReturnValue
@Support
bulkAfterback to summary
public @NotNull LoaderOptionsStep<R> bulkAfter(int number)

Bulk-insert a given number of statements in a single multi-row bulk statement.

If commitEach() is set, each bulk statement will be committed. If commitAfter(int) is set, the given number of bulk statements are committed.

Parameters
number:int

The number of records that are put together in one bulk statement.

Annotations
@NotNull
@CheckReturnValue
@Support
bulkAllback to summary
public @NotNull LoaderOptionsStep<R> bulkAll()

Bulk-insert all rows in a single multi-row bulk statement.

If commitEach() or commitAfter(int) are set, this will force the COMMIT option to commitAll().

Annotations
@NotNull
@CheckReturnValue
@Support
bulkNoneback to summary
public @NotNull LoaderOptionsStep<R> bulkNone()

Do not bulk-insert rows in multi-row bulk statements.

If you don't specify a BULK OPTION, this will be the default.

Annotations
@NotNull
@CheckReturnValue
@Support
commitAfterback to summary
public @NotNull LoaderOptionsStep<R> commitAfter(int number)

Commit after a certain number of batches.

With this clause, errors will never result in a rollback, even when you specify onDuplicateKeyError() or onErrorAbort()

The COMMIT OPTIONS might be useful for fine-tuning performance behaviour in some RDBMS, where large commits lead to a high level of concurrency in the database. Use this on fresh transactions only. Commits/Rollbacks are executed directly upon the connection returned by Configuration#connectionProvider(). This might not work with container-managed transactions, or when Connection#getAutoCommit() is set to true.

If you don't specify a COMMIT OPTION, commitNone() will be the default, leaving transaction handling up to you.

Parameters
number:int

The number of records that are committed together.

Annotations
@NotNull
@CheckReturnValue
@Support
commitAllback to summary
public @NotNull LoaderOptionsStep<R> commitAll()

Commit only after inserting all batches. If this is used together with onDuplicateKeyError() or onErrorAbort(), an abort will result in a rollback of previously loaded records.

The COMMIT OPTIONS might be useful for fine-tuning performance behaviour in some RDBMS, where large commits lead to a high level of concurrency in the database. Use this on fresh transactions only. Commits/Rollbacks are executed directly upon the connection returned by Configuration#connectionProvider(). This might not work with container-managed transactions, or when Connection#getAutoCommit() is set to true.

If you don't specify a COMMIT OPTION, commitNone() will be the default, leaving transaction handling up to you.

Annotations
@NotNull
@CheckReturnValue
@Support
commitEachback to summary
public @NotNull LoaderOptionsStep<R> commitEach()

Commit each batch.

This is the same as calling commitAfter(int) with 1 as parameter.

With this clause, errors will never result in a rollback, even when you specify onDuplicateKeyError() or onErrorAbort()

The COMMIT OPTIONS might be useful for fine-tuning performance behaviour in some RDBMS, where large commits lead to a high level of concurrency in the database. Use this on fresh transactions only. Commits/Rollbacks are executed directly upon the connection returned by Configuration#connectionProvider(). This might not work with container-managed transactions, or when Connection#getAutoCommit() is set to true.

If you don't specify a COMMIT OPTION, commitNone() will be the default, leaving transaction handling up to you.

Annotations
@NotNull
@CheckReturnValue
@Support
commitNoneback to summary
public @NotNull LoaderOptionsStep<R> commitNone()

Leave committing / rollbacking up to client code.

The COMMIT OPTIONS might be useful for fine-tuning performance behaviour in some RDBMS, where large commits lead to a high level of concurrency in the database.

If you don't specify a COMMIT OPTION, this will be the default, leaving transaction handling up to you. This should be your choice, when you use container-managed transactions, too, or your Connection#getAutoCommit() value is set to true.

Annotations
@NotNull
@CheckReturnValue
@Support
onDuplicateKeyErrorback to summary
public @NotNull LoaderOptionsStep<R> onDuplicateKeyError()

Instruct the Loader to cause an error in loading if there are any duplicate records.

If this is combined with onErrorAbort() and commitAll() in a later step of Loader, then loading is rollbacked on abort.

If you don't specify a behaviour, this will be the default. This cannot be combined with onDuplicateKeyIgnore() or onDuplicateKeyUpdate()

Annotations
@NotNull
@CheckReturnValue
@Support
onDuplicateKeyIgnoreback to summary
public @NotNull LoaderOptionsStep<R> onDuplicateKeyIgnore()

Instruct the Loader to skip duplicate records if any of the unique keys' values are already in the database.

If the loaded table does not have any unique keys, then all records are inserted. This may influence the JDBC driver's outcome on Connection#getWarnings(), depending on your JDBC driver's implementation

If you don't specify a behaviour, onDuplicateKeyError() will be the default. This cannot be combined with onDuplicateKeyError() or onDuplicateKeyUpdate()

Annotations
@NotNull
@CheckReturnValue
@Support
onDuplicateKeyUpdateback to summary
public @NotNull LoaderOptionsStep<R> onDuplicateKeyUpdate()

Instruct the Loader to update duplicate records if any of the unique keys' values are already in the database. This is only supported if InsertQuery#onDuplicateKeyUpdate(boolean) is supported, too.

If the loaded table does not have any unqiue keys, then all records are inserted and this clause behaves like onDuplicateKeyIgnore()

If you don't specify a behaviour, onDuplicateKeyError() will be the default. This cannot be combined with onDuplicateKeyError() or onDuplicateKeyIgnore()

Annotations
@NotNull
@CheckReturnValue
@Support:CUBRID, DERBY, H2, HSQLDB, MARIADB, MYSQL, POSTGRES, SQLITE
onErrorAbortback to summary
public @NotNull LoaderOptionsStep<R> onErrorAbort()

Instruct the Loader to abort loading after the first error that might occur when inserting a record. After loading, you can access errors with Loader#errors()

If this is combined with commitAll() in a later step of Loader, then loading is rollbacked on abort.

If you don't specify a behaviour, this will be the default. This cannot be combined with onErrorIgnore()

Annotations
@NotNull
@CheckReturnValue
@Support
onErrorIgnoreback to summary
public @NotNull LoaderOptionsStep<R> onErrorIgnore()

Instruct the Loader to ignore any errors that might occur when inserting a record. The Loader will then skip the record and try inserting the next one. After loading, you can access errors with Loader#errors()

If you don't specify a behaviour, onErrorAbort() will be the default. This cannot be combined with onErrorAbort()

Annotations
@NotNull
@CheckReturnValue
@Support