Module org.jooq
Package org.jooq

Interface LoaderOptionsStep<R extends Record>

  • All Superinterfaces:
    LoaderSourceStep<R>

    public interface LoaderOptionsStep<R extends Record>
    extends LoaderSourceStep<R>
    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.

    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:

    • They're operating on mutable implementations (as of jOOQ 3.x)
    • They're less composable and not easy to get right when dynamic SQL gets complex
    • They're less readable
    • They might have binary incompatible changes between minor releases
    Author:
    Lukas Eder
    • Method Detail

      • onErrorIgnore

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

      • onErrorAbort

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

      • commitEach

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

      • commitAfter

        @NotNull
        @Support
        @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 - The number of records that are committed together.
      • commitAll

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

      • commitNone

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

      • batchNone

        @NotNull
        @Support
        @NotNull LoaderOptionsStep<R> batchNone()
        Do not batch bulk statements together.

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

      • batchAfter

        @NotNull
        @Support
        @NotNull LoaderOptionsStep<R> batchAfter​(int number)
        Batch a given number of bulk statements together.
        Parameters:
        number - The number of records that are batched together.
      • bulkNone

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

      • bulkAfter

        @NotNull
        @Support
        @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 - The number of records that are put together in one bulk statement.