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
 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, loadXML, loadXML, loadXML, loadXML, loadXML
 

Method Detail

onDuplicateKeyUpdate

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 main 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

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 main 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

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

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

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

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 Configuration.getConnection(). 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

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 Configuration.getConnection(). 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

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 Configuration.getConnection(). 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

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.



Copyright © 2012. All Rights Reserved.