• Interfaces
    Interface
    Description
    - [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directly

    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
    - [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directly

    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
    - [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directly

    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
    - [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directly

    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
    - [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directly

    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
    - [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directly
    - [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directly

    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
    - [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directly

    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
    - [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directly

    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
    - 2.6.0 [#1881] - This type will be removed from the public API, soon. Its methods will be pushed down into extending interfaces. Do not reference this type directly.
    - [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directly
    - [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directly

    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
    - [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directly

    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
    - [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directly

    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
    - [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directly

    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
    - [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directly

    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
    - [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directly
    - [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directly
    - [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directly
    - [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directly
    - [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directly

    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
    - [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directly

    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
    - [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directly

    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
    - [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directly

    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
    - [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directly

    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
    - [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directly

    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
    - [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directly
    - [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directly

    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
    - [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directly

    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
    - [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directly
    - [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directly
    - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, via DSLContext.mergeInto(Table)
    - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, via DSLContext.mergeInto(Table)
    - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, via DSLContext.mergeInto(Table)
    - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, via DSLContext.mergeInto(Table)
    - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, via DSLContext.mergeInto(Table)
    - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, via DSLContext.mergeInto(Table)
    - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, via DSLContext.mergeInto(Table)
    - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, via DSLContext.mergeInto(Table)
    - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, via DSLContext.mergeInto(Table)
    - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, via DSLContext.mergeInto(Table)
    - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, via DSLContext.mergeInto(Table)
    - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, via DSLContext.mergeInto(Table)
    - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, via DSLContext.mergeInto(Table)
    - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, via DSLContext.mergeInto(Table)
    - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, via DSLContext.mergeInto(Table)
    - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, via DSLContext.mergeInto(Table)
    - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, via DSLContext.mergeInto(Table)
    - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, via DSLContext.mergeInto(Table)
    - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, via DSLContext.mergeInto(Table)
    - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, via DSLContext.mergeInto(Table)
    - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, via DSLContext.mergeInto(Table)
    - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, via DSLContext.mergeInto(Table)
    - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, via DSLContext.mergeInto(Table)
    - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, via DSLContext.mergeInto(Table)
    - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, via DSLContext.mergeInto(Table)
    - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, via DSLContext.mergeInto(Table)
    - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, via DSLContext.mergeInto(Table)
    - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, via DSLContext.mergeInto(Table)
    - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, via DSLContext.mergeInto(Table)
    - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, via DSLContext.mergeInto(Table)
    - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, via DSLContext.mergeInto(Table)
    - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, via DSLContext.mergeInto(Table)
    - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, via DSLContext.mergeInto(Table)
    - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, via DSLContext.mergeInto(Table)
    - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, via DSLContext.mergeInto(Table)
    - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, via DSLContext.mergeInto(Table)
    - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, via DSLContext.mergeInto(Table)
    - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, via DSLContext.mergeInto(Table)
    - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, via DSLContext.mergeInto(Table)
    - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, via DSLContext.mergeInto(Table)
    - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, via DSLContext.mergeInto(Table)
    - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, via DSLContext.mergeInto(Table)
    - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, via DSLContext.mergeInto(Table)
    - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, via DSLContext.mergeInto(Table)
    - 3.15.0 - [#11902] - Use Iterable.forEach(Consumer) based methods, instead.
    - [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directly

    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
    - [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directly

    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
    - [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directly
    - [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directly
    - [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directly