org.jooq

Interface LoaderOptionsStep<R extends TableRecord<R>>

All Superinterfaces:

LoaderSourceStep<R>

public interface LoaderOptionsStep<R extends TableRecord<R>>
extends LoaderSourceStep<R>

The Loader API is used for configuring data loads.

Add options to for the loading behaviour

Author:

Lukas Eder

Method Summary

Modifier and Type	Method and Description
LoaderOptionsStep<R>	commitAfter(int number) Commit after a certain number of inserted records.
LoaderOptionsStep<R>	commitAll() Commit only after inserting all records.
LoaderOptionsStep<R>	commitEach() Commit each loaded record.
LoaderOptionsStep<R>	commitNone() Leave committing / rollbacking up to client code.
LoaderOptionsStep<R>	onDuplicateKeyError() Instruct the Loader to cause an error in loading if there are any duplicate records.
LoaderOptionsStep<R>	onDuplicateKeyIgnore() Instruct the Loader to skip duplicate records if the main unique key's value is already in the database.
LoaderOptionsStep<R>	onDuplicateKeyUpdate() Instruct the Loader to update duplicate records if the main unique key's value is already in the database.
LoaderOptionsStep<R>	onErrorAbort() Instruct the Loader to abort loading after the first error that might occur when inserting a record.
LoaderOptionsStep<R>	onErrorIgnore() Instruct the Loader to ignore any errors that might occur when inserting a record.

Methods inherited from interface org.jooq.LoaderSourceStep

loadCSV, loadCSV, loadCSV, loadCSV, loadJSON, loadJSON, loadJSON, loadJSON, loadXML, loadXML, loadXML, loadXML, loadXML

Method Detail

onDuplicateKeyUpdate

@Support(value={CUBRID,DB2,HSQLDB,MARIADB,MYSQL,ORACLE,SQLSERVER,SYBASE})
LoaderOptionsStep<R> onDuplicateKeyUpdate()

Instruct the Loader to update duplicate records if the main unique key's value is already in the database. This is only supported if InsertQuery.onDuplicateKeyUpdate(boolean) is supported, too.

If the loaded table does not have a primary key, 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()

onDuplicateKeyIgnore

@Support
LoaderOptionsStep<R> onDuplicateKeyIgnore()

Instruct the Loader to skip duplicate records if the main unique key's value is already in the database.

If the loaded table does not have a primary key, 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()

onDuplicateKeyError

@Support
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()

onErrorIgnore

@Support
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()

onErrorAbort

@Support
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()

commitEach

@Support
LoaderOptionsStep<R> commitEach()

Commit each loaded record. This will prevent batch INSERT's altogether. Otherwise, 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.

commitAfter

@Support
LoaderOptionsStep<R> commitAfter(int number)

Commit after a certain number of inserted records. This may enable batch INSERT's for at most number records.

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 - The number of records that are committed together.

commitAll

@Support
LoaderOptionsStep<R> commitAll()

Commit only after inserting all records. 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.

commitNone

@Support
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.