• Deprecated 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

    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

    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
    - 3.17.0 - [#13005] - Use TableElement 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
    - [#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
  • Deprecated Annotation Interfaces
    Annotation Interface
    Description
    - 3.17.0 - [#13071] - Use ApiStatus.Internal instead.
  • Deprecated Enum Constants
    Enum Constant
    Description
    - [#9403] - 3.13.0 - This dialect is hardly used by anyone with jOOQ or without jOOQ and will be removed in the near future.
    - [#12465] - 3.16.0 - This dialect is hardly used by anyone with jOOQ or without jOOQ and will be removed in the near future. If you're actively using this dialect, please get in touch for extended support: https://github.com/jOOQ/jOOQ/issues/12465
    - [#11515] - 3.15.0 - This dialect is hardly used by anyone with jOOQ or without jOOQ and will be removed in the near future. If you're actively using this dialect, please get in touch for extended support: https://github.com/jOOQ/jOOQ/issues/11515
    - [#11797] - 3.15.0 - This dialect is no longer supported. If you continue to require support for Oracle 10g, please get in touch here: https://github.com/jOOQ/jOOQ/issues/11797
    - This dialect is not yet supported by jOOQ.