org.jooq.LoaderOptionsStep Maven / Gradle / Ivy
/**
* Copyright (c) 2009-2016, Data Geekery GmbH (http://www.datageekery.com)
* All rights reserved.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*
* Other licenses:
* -----------------------------------------------------------------------------
* Commercial licenses for this work are available. These replace the above
* ASL 2.0 and offer limited warranties, support, maintenance, and commercial
* database integrations.
*
* For more information, please visit: http://www.jooq.org/licenses
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*/
package org.jooq;
import static org.jooq.SQLDialect.CUBRID;
// ...
import static org.jooq.SQLDialect.HSQLDB;
import static org.jooq.SQLDialect.MARIADB;
import static org.jooq.SQLDialect.MYSQL;
// ...
import static org.jooq.SQLDialect.POSTGRES_9_5;
// ...
// ...
import java.sql.Connection;
/**
* 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:
*
* - The bulk statement size. This specifies how many rows
* will be inserted in a single bulk statement / multi-row
INSERT
* statement.
* - The batch statement size. This specifies how many bulk
* statements will be sent to the server as a single JDBC batch statement.
* - The commit size. This specifies how many batch
* statements will be committed in a single transaction.
*
*
* @author Lukas Eder
*/
public interface LoaderOptionsStep extends LoaderSourceStep {
// -------------------------------------------------------------------------
// Duplicate handling
// -------------------------------------------------------------------------
/**
* Instruct the Loader to update duplicate records if the main
* unique key's value is already in the database. This is only supported if
* {@link 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 {@link #onDuplicateKeyIgnore()}
*
* If you don't specify a behaviour, {@link #onDuplicateKeyError()} will be
* the default. This cannot be combined with {@link #onDuplicateKeyError()}
* or {@link #onDuplicateKeyIgnore()}
*/
@Support({ CUBRID, HSQLDB, MARIADB, MYSQL, POSTGRES_9_5 })
LoaderOptionsStep onDuplicateKeyUpdate();
/**
* 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
* {@link Connection#getWarnings()}, depending on your JDBC driver's
* implementation
*
* If you don't specify a behaviour, {@link #onDuplicateKeyError()} will be
* the default. This cannot be combined with {@link #onDuplicateKeyError()}
* or {@link #onDuplicateKeyUpdate()}
*/
@Support
LoaderOptionsStep onDuplicateKeyIgnore();
/**
* Instruct the Loader to cause an error in loading if there
* are any duplicate records.
*
* If this is combined with {@link #onErrorAbort()} and {@link #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 {@link #onDuplicateKeyIgnore()} or
* {@link #onDuplicateKeyUpdate()}
*/
@Support
LoaderOptionsStep onDuplicateKeyError();
// -------------------------------------------------------------------------
// Error handling
// -------------------------------------------------------------------------
/**
* 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 {@link Loader#errors()}
*
* If you don't specify a behaviour, {@link #onErrorAbort()} will be the
* default. This cannot be combined with {@link #onErrorAbort()}
*/
@Support
LoaderOptionsStep onErrorIgnore();
/**
* Instruct the Loader to abort loading after the first error
* that might occur when inserting a record. After loading, you can access
* errors with {@link Loader#errors()}
*
* If this is combined with {@link #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 {@link #onErrorIgnore()}
*/
@Support
LoaderOptionsStep onErrorAbort();
// -------------------------------------------------------------------------
// Commit strategy
// -------------------------------------------------------------------------
/**
* Commit each batch.
*
* This is the same as calling {@link #commitAfter(int)} with 1
* as parameter.
*
* With this clause, errors will never result in a rollback, even when you
* specify {@link #onDuplicateKeyError()} or {@link #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
* {@link Configuration#connectionProvider()}. This might not work with
* container-managed transactions, or when
* {@link Connection#getAutoCommit()} is set to true.
*
* If you don't specify a COMMIT OPTION, {@link #commitNone()} will be the
* default, leaving transaction handling up to you.
*/
@Support
LoaderOptionsStep commitEach();
/**
* Commit after a certain number of batches.
*
* With this clause, errors will never result in a rollback, even when you
* specify {@link #onDuplicateKeyError()} or {@link #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
* {@link Configuration#connectionProvider()}. This might not work with
* container-managed transactions, or when
* {@link Connection#getAutoCommit()} is set to true.
*
* If you don't specify a COMMIT OPTION, {@link #commitNone()} will be the
* default, leaving transaction handling up to you.
*
* @param number The number of records that are committed together.
*/
@Support
LoaderOptionsStep commitAfter(int number);
/**
* Commit only after inserting all batches. If this is used together with
* {@link #onDuplicateKeyError()} or {@link #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
* {@link Configuration#connectionProvider()}. This might not work with
* container-managed transactions, or when
* {@link Connection#getAutoCommit()} is set to true.
*
* If you don't specify a COMMIT OPTION, {@link #commitNone()} will be the
* default, leaving transaction handling up to you.
*/
@Support
LoaderOptionsStep commitAll();
/**
* 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
* {@link Connection#getAutoCommit()} value is set to true.
*/
@Support
LoaderOptionsStep commitNone();
// -------------------------------------------------------------------------
// Batch strategy
// -------------------------------------------------------------------------
/**
* Batch all bulk statements in one JDBC batch statement.
*
* If {@link #commitEach()} or {@link #commitAfter(int)} are set, this will
* force the COMMIT option to {@link #commitAll()}.
*/
@Support
LoaderOptionsStep batchAll();
/**
* Do not batch bulk statements together.
*
* If you don't specify a BATCH OPTION, this will be the default.
*/
@Support
LoaderOptionsStep batchNone();
/**
* Batch a given number of bulk statements together.
*
* @param number The number of records that are batched together.
*/
@Support
LoaderOptionsStep batchAfter(int number);
// -------------------------------------------------------------------------
// Bulk strategy
// -------------------------------------------------------------------------
/**
* Bulk-insert all rows in a single multi-row bulk statement.
*
* If {@link #commitEach()} or {@link #commitAfter(int)} are set, this will
* force the COMMIT option to {@link #commitAll()}.
*/
@Support
LoaderOptionsStep bulkAll();
/**
* Do not bulk-insert rows in multi-row bulk statements.
*
* If you don't specify a BULK OPTION, this will be the default.
*/
@Support
LoaderOptionsStep bulkNone();
/**
* Bulk-insert a given number of statements in a single multi-row bulk
* statement.
*
* If {@link #commitEach()} is set, each bulk statement will be committed.
* If {@link #commitAfter(int)} is set, the given number of bulk statements
* are committed.
*
* @param number The number of records that are put together in one bulk
* statement.
*/
@Support
LoaderOptionsStep bulkAfter(int number);
}