Deprecated API
Contents
-
Terminally Deprecated ElementsElementDescription- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directly
Referencing
XYZ*Steptypes directly from client codeIt is usually not recommended to reference any
XYZ*Steptypes 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*Steptypes 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 directlyReferencing
XYZ*Steptypes directly from client codeIt is usually not recommended to reference any
XYZ*Steptypes 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*Steptypes 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 directlyReferencing
XYZ*Steptypes directly from client codeIt is usually not recommended to reference any
XYZ*Steptypes 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*Steptypes 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 directlyReferencing
XYZ*Steptypes directly from client codeIt is usually not recommended to reference any
XYZ*Steptypes 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*Steptypes 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 directlyReferencing
XYZ*Steptypes directly from client codeIt is usually not recommended to reference any
XYZ*Steptypes 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*Steptypes 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 directlyReferencing
XYZ*Steptypes directly from client codeIt is usually not recommended to reference any
XYZ*Steptypes 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*Steptypes 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.11.0 - [#7258] - This part of theVisitListenerSPI is deprecated. There are currently no plans of replacing it. Please get in touch if you think this functionality needs to be kept in one way or another: https://github.com/jOOQ/jOOQ/issues/7258- 3.10 - [#6254] - This functionality is no longer supported and will be removed in 4.0- 3.10 - [#6254] - This functionality is no longer supported and will be removed in 4.0- 3.10 - [#6254] - This functionality is no longer supported and will be removed in 4.0- 3.10 - [#6254] - This functionality is no longer supported and will be removed in 4.0- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directlyReferencing
XYZ*Steptypes directly from client codeIt is usually not recommended to reference any
XYZ*Steptypes 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*Steptypes 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.14.0 - [#9911] - This method is no longer supported.- 3.14.0 - [#9911] - This method is no longer supported.- 3.14.0 - [#9911] - This method is no longer supported.- 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.- 2.0.5 - UseConfiguration.settings()instead- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directly- [#10317] - 3.14.0 - Do not reuse this method. It will be removed without replacement.- [#10317] - 3.14.0 - Do not reuse this method. It will be removed without replacement.- 3.10.0 - [#4990] - UseDSL.keyword(String)instead.- 3.10.0 - [#4990] - Use any ofDSL.name(String),DSL.quotedName(String)orDSL.unquotedName(String)instead.- [#10689] - 3.14.0 - This converter does not work. Do not use this method, useConverters.identity(Class)instead.- [#10689] - 3.14.0 - This method does not provide any useful functionality and will be removed in the future.- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directlyReferencing
XYZ*Steptypes directly from client codeIt is usually not recommended to reference any
XYZ*Steptypes 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*Steptypes 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 directlyReferencing
XYZ*Steptypes directly from client codeIt is usually not recommended to reference any
XYZ*Steptypes 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*Steptypes 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 directlyReferencing
XYZ*Steptypes directly from client codeIt is usually not recommended to reference any
XYZ*Steptypes 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*Steptypes 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 directlyReferencing
XYZ*Steptypes directly from client codeIt is usually not recommended to reference any
XYZ*Steptypes 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*Steptypes 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 directlyReferencing
XYZ*Steptypes directly from client codeIt is usually not recommended to reference any
XYZ*Steptypes 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*Steptypes 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 directlyReferencing
XYZ*Steptypes directly from client codeIt is usually not recommended to reference any
XYZ*Steptypes 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*Steptypes 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- 3.10 - [#6363] - UseCursor.fetchNext(int)instead.- 3.15.0 - [#11902] - UseIterable.forEach(Consumer)based methods, instead.- 3.15.0 - [#11902] - UseIterable.forEach(Consumer)based methods, instead.- 3.10 - [#6363] - UseCursor.fetchNext()instead.- 3.10 - [#6363] - UseCursor.fetchNext(RecordMapper)instead.- 3.10 - [#6363] - UseCursor.fetchNextInto(RecordHandler)instead.- 3.10 - [#6363] - UseCursor.fetchNextInto(Class)instead.- 3.10 - [#6363] - UseCursor.fetchNextInto(Table)instead.- 3.10 - [#6363] - UseCursor.fetchNextOptional()instead.- 3.10 - [#6363] - UseCursor.fetchNextOptional(RecordMapper)instead.- 3.10 - [#6363] - UseCursor.fetchNextOptionalInto(Class)instead.- 3.10 - [#6363] - UseCursor.fetchNextOptionalInto(Table)instead.- [#3852] - 3.8.0 - UseDataType.defaultValue(Field)instead.- [#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 directlyReferencing
XYZ*Steptypes directly from client codeIt is usually not recommended to reference any
XYZ*Steptypes 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*Steptypes 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 directlyReferencing
XYZ*Steptypes directly from client codeIt is usually not recommended to reference any
XYZ*Steptypes 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*Steptypes 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 directlyReferencing
XYZ*Steptypes directly from client codeIt is usually not recommended to reference any
XYZ*Steptypes 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*Steptypes 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 directlyReferencing
XYZ*Steptypes directly from client codeIt is usually not recommended to reference any
XYZ*Steptypes 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*Steptypes 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 directlyReferencing
XYZ*Steptypes directly from client codeIt is usually not recommended to reference any
XYZ*Steptypes 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*Steptypes 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 directlyReferencing
XYZ*Steptypes directly from client codeIt is usually not recommended to reference any
XYZ*Steptypes 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*Steptypes 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 directlyReferencing
XYZ*Steptypes directly from client codeIt is usually not recommended to reference any
XYZ*Steptypes 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*Steptypes 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
- [#6280] - 3.10 - Do not reuse this method. It will be completely internal with jOOQ 4.0- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#6280] - 3.10 - Do not reuse this method. It will be completely internal with jOOQ 4.0- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.11 - [#7538] - UseDSL.abs(Field)instead.- 3.11 - [#7538] - UseDSL.acos(Field)instead.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.13 - [#9407] - UseDSL.ascii(Field)instead.- 3.11 - [#7538] - UseDSL.asin(Field)instead.- 3.11 - [#7538] - UseDSL.atan(Field)instead.- 3.11 - [#7538] - UseDSL.atan2(Field, Number)instead.- 3.11 - [#7538] - UseDSL.atan2(Field, Field)instead.- 3.11 - [#7538] - UseDSL.avg(Field)instead.- 3.11 - [#7538] - UseDSL.avg(Field)instead.- 3.13 - [#9407] - UseDSL.bitLength(Field)instead.- 3.11 - [#7538] - UseDSL.ceil(Field)instead.- 3.13 - [#9407] - UseDSL.charLength(Field)instead.- 3.13 - [#9407] - UseDSL.coalesce(Field, Field...)instead.- 3.13 - [#9407] - UseDSL.coalesce(Object, Object...)instead.- 3.11 - [#7538] - UseDSL.cos(Field)instead.- 3.11 - [#7538] - UseDSL.cosh(Field)instead.- 3.11 - [#7538] - UseDSL.cot(Field)instead.- 3.11 - [#7538] - UseDSL.coth(Field)instead.- 3.11 - [#7538] - UseDSL.count(Field)instead.- 3.11 - [#7538] - UseDSL.countDistinct(Field)instead.- 3.11 - [#7538] - UseDSL.count(Field)instead.- 3.13 - [#9407] - UseDSL.decode(Field, Field, Field)instead.- 3.13 - [#9407] - UseDSL.decode(Field, Field, Field, Field...)instead.- 3.13 - [#9407] - UseDSL.decode(Object, Object, Object)instead.- 3.13 - [#9407] - UseDSL.decode(Object, Object, Object, Object...)instead.- 3.11 - [#7538] - UseDSL.deg(Field)instead.- 3.11 - [#7538] - UseDSL.exp(Field)instead.- 3.11 - [#7538] - UseDSL.extract(Field, DatePart)instead.- 3.11 - [#7538] - UseDSL.firstValue(Field)instead.- 3.11 - [#7538] - UseDSL.floor(Field)instead.- 3.11 - [#7538] - UseDSL.greatest(Field, Field...)instead.- 3.11 - [#7538] - UseDSL.greatest(Field, Field...)instead.- 3.11 - [#7538] - UseDSL.lag(Field)instead.- 3.11 - [#7538] - UseDSL.lag(Field, int)instead.- 3.11 - [#7538] - UseDSL.lag(Field, int, Field)instead.- 3.11 - [#7538] - UseDSL.lag(Field, int, Object)instead.- 3.11 - [#7538] - UseDSL.lastValue(Field)instead.- 3.11 - [#7538] - UseDSL.lead(Field)instead.- 3.11 - [#7538] - UseDSL.lead(Field, int)instead.- 3.11 - [#7538] - UseDSL.lead(Field, int, Field)instead.- 3.11 - [#7538] - UseDSL.lead(Field, int, Object)instead.- 3.11 - [#7538] - UseDSL.least(Field, Field...)instead.- 3.11 - [#7538] - UseDSL.least(Field, Field...)instead.- 3.13 - [#9407] - UseDSL.length(Field)instead.- 3.11 - [#7538] - UseDSL.ln(Field)instead.- 3.11 - [#7538] - UseDSL.log(Field, int)instead.- 3.13 - [#9407] - UseDSL.lower(Field)instead.- 3.13 - [#9407] - UseDSL.lpad(Field, int)instead.- 3.13 - [#9407] - UseDSL.lpad(Field, int, char)instead.- 3.13 - [#9407] - UseDSL.lpad(Field, Field)instead.- 3.13 - [#9407] - UseDSL.lpad(Field, Field, Field)instead.- 3.13 - [#9407] - UseDSL.ltrim(Field)instead.- 3.11 - [#7538] - UseDSL.max(Field)instead.- 3.11 - [#7538] - UseDSL.max(Field)instead.- 3.11 - [#7538] - UseDSL.median(Field)instead.- 3.11 - [#7538] - UseDSL.min(Field)instead.- 3.11 - [#7538] - UseDSL.min(Field)instead.- 3.13 - [#9407] - UseDSL.nullif(Field, Field)instead.- 3.13 - [#9407] - UseDSL.nullif(Field, Object)instead.- 3.13 - [#9407] - UseDSL.nvl(Field, Field)instead.- 3.13 - [#9407] - UseDSL.nvl(Field, Object)instead.- 3.13 - [#9407] - UseDSL.nvl2(Field, Field, Field)instead.- 3.13 - [#9407] - UseDSL.nvl2(Field, Object, Object)instead.- 3.13 - [#9407] - UseDSL.octetLength(Field)instead.- 3.13 - [#9407] - UseDSL.position(Field, String)instead.- 3.13 - [#9407] - UseDSL.position(Field, Field)instead.- 3.11 - [#7538] - UseDSL.rad(Field)instead.- 3.13 - [#9407] - UseDSL.repeat(Field, int)instead.- 3.13 - [#9407] - UseDSL.repeat(Field, Field)instead.- 3.13 - [#9407] - UseDSL.replace(Field, String)instead.- 3.13 - [#9407] - UseDSL.replace(Field, String, String)instead.- 3.13 - [#9407] - UseDSL.replace(Field, Field)instead.- 3.13 - [#9407] - UseDSL.replace(Field, Field, Field)instead.- 3.11 - [#7538] - UseDSL.round(Field)instead.- 3.11 - [#7538] - UseDSL.round(Field, int)instead.- 3.13 - [#9407] - UseDSL.rpad(Field, int)instead.- 3.13 - [#9407] - UseDSL.rpad(Field, int, char)instead.- 3.13 - [#9407] - UseDSL.rpad(Field, Field)instead.- 3.13 - [#9407] - UseDSL.rpad(Field, Field, Field)instead.- 3.13 - [#9407] - UseDSL.rtrim(Field)instead.- 3.11 - [#7538] - UseDSL.sign(Field)instead.- 3.11 - [#7538] - UseDSL.sin(Field)instead.- 3.11 - [#7538] - UseDSL.sinh(Field)instead.- 3.11 - [#7538] - UseDSL.sqrt(Field)instead.- 3.11 - [#7538] - UseDSL.stddevPop(Field)instead.- 3.11 - [#7538] - UseDSL.stddevPop(Field)instead.- 3.11 - [#7538] - UseDSL.stddevSamp(Field)instead.- 3.11 - [#7538] - UseDSL.stddevSamp(Field)instead.- 3.13 - [#9407] - UseDSL.substring(Field, int)instead.- 3.13 - [#9407] - UseDSL.substring(Field, int, int)instead.- 3.13 - [#9407] - UseDSL.substring(Field, Field)instead.- 3.13 - [#9407] - UseDSL.substring(Field, Field, Field)instead.- 3.11 - [#7538] - UseDSL.sum(Field)instead.- 3.11 - [#7538] - UseDSL.sum(Field)instead.- 3.11 - [#7538] - UseDSL.tan(Field)instead.- 3.11 - [#7538] - UseDSL.tanh(Field)instead.- 3.13 - [#9407] - UseDSL.trim(Field)instead.- 3.13 - [#9407] - UseDSL.upper(Field)instead.- 3.11 - [#7538] - UseDSL.varPop(Field)instead.- 3.11 - [#7538] - UseDSL.varPop(Field)instead.- 3.11 - [#7538] - UseDSL.varSamp(Field)instead.- 3.11 - [#7538] - UseDSL.varSamp(Field)instead.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directlyReferencing
XYZ*Steptypes directly from client codeIt is usually not recommended to reference any
XYZ*Steptypes 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*Steptypes 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.11 - [#6631] - UseDefaultBinding.binding(Converter)instead.- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDefaultDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDefaultDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDefaultDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDefaultDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDefaultDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDefaultDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDefaultDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDefaultDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDefaultDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDefaultDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDefaultDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDefaultDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDefaultDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDefaultDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDefaultDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDefaultDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDefaultDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDefaultDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDefaultDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDefaultDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDefaultDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDefaultDSLContext.mergeInto(Table)- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.11.0 - [#7483] - The (indirect) use of the internal static data type registry is not recommended.- [#7956] - 3.12.0 - UseDSL.groupConcat(Field)andGroupConcatSeparatorStep.separator(String)instead.- [#15196] - 3.19.0 - The semantics of theFieldarguments in this method is inconsistent with that of other overloads, such asDSL.jsonbObject(Field, Field), which can lead to subtle bugs. Please refrain from using this overload as it will be removed in the future. UseDSL.jsonObject(JSONEntry...)instead.- [#15196] - 3.19.0 - The semantics of theFieldarguments in this method is inconsistent with that of other overloads, such asDSL.jsonbObject(Field, Field), which can lead to subtle bugs. Please refrain from using this overload as it will be removed in the future. UseDSL.jsonObject(JSONEntry...)instead.- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSL.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSL.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSL.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSL.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSL.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSL.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSL.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSL.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSL.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSL.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSL.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSL.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSL.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSL.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSL.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSL.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSL.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSL.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSL.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSL.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSL.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSL.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSL.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSL.mergeInto(Table)- [#11092] - 3.15.0 - This method will be removed without public replacement.- [#11092] - 3.15.0 - This method will be removed without public replacement.- [#11092] - 3.15.0 - This method will be removed without public replacement.- [#11092] - 3.15.0 - This method will be removed without public replacement.- [#11092] - 3.15.0 - This method will be removed without public replacement.- [#11092] - 3.15.0 - This method will be removed without public replacement.- [#11092] - 3.15.0 - This method will be removed without public replacement.- [#11812] - 3.15.0 - UseRow1as aSelectFielddirectly, instead.- [#11812] - 3.15.0 - UseRow10as aSelectFielddirectly, instead.- [#11812] - 3.15.0 - UseRow11as aSelectFielddirectly, instead.- [#11812] - 3.15.0 - UseRow12as aSelectFielddirectly, instead.- [#11812] - 3.15.0 - UseRow13as aSelectFielddirectly, instead.- [#11812] - 3.15.0 - UseRow14as aSelectFielddirectly, instead.- [#11812] - 3.15.0 - UseRow15as aSelectFielddirectly, instead.- [#11812] - 3.15.0 - UseRow16as aSelectFielddirectly, instead.- [#11812] - 3.15.0 - UseRow17as aSelectFielddirectly, instead.- [#11812] - 3.15.0 - UseRow18as aSelectFielddirectly, instead.- [#11812] - 3.15.0 - UseRow19as aSelectFielddirectly, instead.- [#11812] - 3.15.0 - UseRow2as aSelectFielddirectly, instead.- [#11812] - 3.15.0 - UseRow20as aSelectFielddirectly, instead.- [#11812] - 3.15.0 - UseRow21as aSelectFielddirectly, instead.- [#11812] - 3.15.0 - UseRow22as aSelectFielddirectly, instead.- [#11812] - 3.15.0 - UseRow3as aSelectFielddirectly, instead.- [#11812] - 3.15.0 - UseRow4as aSelectFielddirectly, instead.- [#11812] - 3.15.0 - UseRow5as aSelectFielddirectly, instead.- [#11812] - 3.15.0 - UseRow6as aSelectFielddirectly, instead.- [#11812] - 3.15.0 - UseRow7as aSelectFielddirectly, instead.- [#11812] - 3.15.0 - UseRow8as aSelectFielddirectly, instead.- [#11812] - 3.15.0 - UseRow9as aSelectFielddirectly, instead.- [#11812] - 3.15.0 - UseRowNas aSelectFielddirectly, instead.- 3.10 - [#6162] - UseDSL.sequence(Name)instead.- 3.10 - [#6162] - UseDSL.sequence(Name, Class)instead.- 3.10 - [#6162] - UseDSL.sequence(Name, DataType)instead.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#9404] - Please re-generate your code.org.jooq.impl.Internal.createForeignKey(UniqueKey<U>, Table<R>, String, TableField<R, ?>[], boolean) - 3.14.0 - [#9404] - Please re-generate your code.- 3.14.0 - [#9404] - Please re-generate your code.- 3.14.0 - [#9404] - Please re-generate your code.- 3.14.0 - [#9404] - Please re-generate your code.- [#11058] - 3.14.5 - Please re-generate your code.- [#12238] - 3.16.0 - Please re-generate your code.- [#12425] - 3.16.0 - Missing implementations should be added as soon as possible!- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directly- 3.14.0 - [#10010] - UseLoaderCSVStep.fieldsCorresponding()instead.- 3.14.0 - [#10010] - UseLoaderJSONStep.fieldsCorresponding()instead.- 3.14.0 - [#4941] - UseLoaderListenerStep.onRowEnd(LoaderRowListener)instead.- 3.14.0 - [#10010] - UseLoaderRowsStep.fieldsCorresponding()instead.- [#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, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.12.0 - [#8163] - UsePivotForStep.for_(Field)instead.- 3.10 - [#6143] - UseQueries.queryStream()instead.- 3.15.0 - [#11902] - UseIterable.forEach(Consumer)based methods, instead.- 3.10 - [#6254] - This functionality is no longer supported and will be removed in 4.0- 3.10 - [#6254] - This functionality is no longer supported and will be removed in 4.0- 3.10 - [#6254] - This functionality is no longer supported and will be removed in 4.0- 3.10 - [#6254] - This functionality is no longer supported and will be removed in 4.0- 3.15.0 - [#11902] - UseIterable.forEach(Consumer)based methods, instead.- 3.15.0 - [#11902] - UseIterable.forEach(Consumer)based methods, instead.- 3.10 - [#6254] - This functionality is no longer supported and will be removed in 4.0- 3.10 - [#6254] - This functionality is no longer supported and will be removed in 4.0- 3.10 - [#6254] - This functionality is no longer supported and will be removed in 4.0- 3.10 - [#6254] - This functionality is no longer supported and will be removed in 4.0- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directlyReferencing
XYZ*Steptypes directly from client codeIt is usually not recommended to reference any
XYZ*Steptypes 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*Steptypes 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.0.5 - Use runtime configurationSettingsinstead[#5218] - 3.14.0 - UseSelectQuery.setForLockModeNoWait()[#5218] - 3.14.0 - UseSelectQuery.setForLockModeOf(Collection)[#5218] - 3.14.0 - UseSelectQuery.setForLockModeOf(Field...)[#5218] - 3.14.0 - UseSelectQuery.setForLockModeOf(Table...)[#5218] - 3.14.0 - UseSelectQuery.setForLockModeSkipLocked()[#5218] - 3.14.0 - UseSelectQuery.setForLockModeWait(int)- [#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- [#9882] - 3.14.0 - UseSQLDialect.supportedBy(SQLDialect...)instead- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.15.0 - [#11898] This class will be removed in the future. Do not reuse. Data type conversion happens using internalConverterimplementations, orConverterProviderprovided ones, or implementations attached to fields via generated code, or viaField.convert(Converter), orDataType.asConvertedDataType(Converter).- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directlyReferencing
XYZ*Steptypes directly from client codeIt is usually not recommended to reference any
XYZ*Steptypes 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*Steptypes 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- 3.11.0 - [#7375] - This type is part of jOOQ's internal API. Do not reference this type directly from client code. Referencing this type before theSQLDataTypeclass has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataTypeinstead.- 3.15.0 - [#10796] - This class will be removed, soon, no more vendor specific DSL API will be added.- 3.11.0 - [#7375] - This type is part of jOOQ's internal API. Do not reference this type directly from client code. Referencing this type before theSQLDataTypeclass has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataTypeinstead.- 3.15.0 - [#10796] - This class will be removed, soon, no more vendor specific DSL API will be added.- 3.11.0 - [#7375] - This type is part of jOOQ's internal API. Do not reference this type directly from client code. Referencing this type before theSQLDataTypeclass has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataTypeinstead.- 3.11.0 - [#7375] - This type is part of jOOQ's internal API. Do not reference this type directly from client code. Referencing this type before theSQLDataTypeclass has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataTypeinstead.- 3.11.0 - [#7375] - This type is part of jOOQ's internal API. Do not reference this type directly from client code. Referencing this type before theSQLDataTypeclass has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataTypeinstead.- 3.11.0 - [#7375] - This type is part of jOOQ's internal API. Do not reference this type directly from client code. Referencing this type before theSQLDataTypeclass has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataTypeinstead.- 3.11.0 - [#7375] - This type is part of jOOQ's internal API. Do not reference this type directly from client code. Referencing this type before theSQLDataTypeclass has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataTypeinstead.- 3.13.0 - [#9403] - This dialect is hardly used by anyone with jOOQ or without jOOQ and will be removed in the near future.- 3.11.0 - [#7375] - This type is part of jOOQ's internal API. Do not reference this type directly from client code. Referencing this type before theSQLDataTypeclass has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataTypeinstead.- 3.15.0 - [#10796] - This class will be removed, soon, no more vendor specific DSL API will be added.- 3.11.0 - [#7375] - This type is part of jOOQ's internal API. Do not reference this type directly from client code. Referencing this type before theSQLDataTypeclass has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataTypeinstead.- 3.15.0 - [#10796] - This class will be removed, soon, no more vendor specific DSL API will be added.- 3.11.0 - [#7375] - This type is part of jOOQ's internal API. Do not reference this type directly from client code. Referencing this type before theSQLDataTypeclass has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataTypeinstead.- 3.11.0 - [#7375] - This type is part of jOOQ's internal API. Do not reference this type directly from client code. Referencing this type before theSQLDataTypeclass has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataTypeinstead.- 3.15.0 - [#10796] - This class will be removed, soon, no more vendor specific DSL API will be added.- 3.11.0 - [#7375] - This type is part of jOOQ's internal API. Do not reference this type directly from client code. Referencing this type before theSQLDataTypeclass has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataTypeinstead.- 3.15.0 - [#10796] - This class will be removed, soon, no more vendor specific DSL API will be added.- 3.11.0 - [#7375] - This type is part of jOOQ's internal API. Do not reference this type directly from client code. Referencing this type before theSQLDataTypeclass has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataTypeinstead.- 3.15.0 - [#10796] - This class will be removed, soon, no more vendor specific DSL API will be added.- 3.11.0 - [#7375] - This type is part of jOOQ's internal API. Do not reference this type directly from client code. Referencing this type before theSQLDataTypeclass has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataTypeinstead.- 3.15.0 - [#10796] - This class will be removed, soon, no more vendor specific DSL API will be added.- 3.11.0 - [#7375] - This type is part of jOOQ's internal API. Do not reference this type directly from client code. Referencing this type before theSQLDataTypeclass has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataTypeinstead.- 3.11.0 - [#7375] - This type is part of jOOQ's internal API. Do not reference this type directly from client code. Referencing this type before theSQLDataTypeclass has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataTypeinstead.- 3.15.0 - [#10796] - This class will be removed, soon, no more vendor specific DSL API will be added.- 3.11.0 - [#7375] - This type is part of jOOQ's internal API. Do not reference this type directly from client code. Referencing this type before theSQLDataTypeclass has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataTypeinstead.- 3.15.0 - [#10796] - This class will be removed, soon, no more vendor specific DSL API will be added.- 3.11.0 - [#7375] - This type is part of jOOQ's internal API. Do not reference this type directly from client code. Referencing this type before theSQLDataTypeclass has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataTypeinstead.- 3.11.0 - [#7375] - This type is part of jOOQ's internal API. Do not reference this type directly from client code. Referencing this type before theSQLDataTypeclass has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataTypeinstead.- 3.11.0 - [#7375] - This type is part of jOOQ's internal API. Do not reference this type directly from client code. Referencing this type before theSQLDataTypeclass has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataTypeinstead.- 3.15.0 - [#8611] - This function has been removed from MySQL 8- 3.15.0 - [#8611] - This function has been removed from MySQL 8- 3.15.0 - [#8611] - This function has been removed from MySQL 8- 3.15.0 - [#8611] - This function has been removed from MySQL 8- 3.15.0 - [#8611] - This function has been removed from MySQL 8- 3.15.0 - [#8611] - This function has been removed from MySQL 8- 3.15.0 - [#8611] - This function has been removed from MySQL 8- 3.15.0 - [#8611] - This function has been removed from MySQL 8- 3.15.0 - [#8611] - This function has been removed from MySQL 8- 3.15.0 - [#8611] - This function has been removed from MySQL 8- 3.15.0 - [#8611] - This function has been removed from MySQL 8- 3.15.0 - [#8611] - This function has been removed from MySQL 8- 3.15.0 - [#8611] - This function has been removed from MySQL 8- 3.15.0 - [#8611] - This function has been removed from MySQL 8- 3.15.0 - [#8611] - This function has been removed from MySQL 8- 3.15.0 - [#8611] - This function has been removed from MySQL 8- 3.15.0 - [#8611] - This function has been removed from MySQL 8- 3.15.0 - [#8611] - This function has been removed from MySQL 8- 3.15.0 - [#8611] - This function has been removed from MySQL 8- 3.15.0 - [#8611] - This function has been removed from MySQL 8- 3.15.0 - [#8611] - This function has been removed from MySQL 8- 3.15.0 - [#12099] - MySQL 8.0.20 has deprecated this clause and replaced it by something new, which we'll support soon, see https://dev.mysql.com/doc/refman/8.0/en/insert-on-duplicate.html/ and https://github.com/jOOQ/jOOQ/issues/12099- 3.11.0 - [#7375] - This type is part of jOOQ's internal API. Do not reference this type directly from client code. Referencing this type before theSQLDataTypeclass has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataTypeinstead.- 3.14.0 - [#8381] [#10641] - UseDSL.toChar(Field, Field)instead.- 3.14.0 - [#8381] [#10641] - UseDSL.toChar(Field, Field)instead.- 3.14.0 - [#8381] [#10641] - UseDSL.toChar(Field, Field)instead.- 3.14.0 - [#8381] [#10641] - UseDSL.toChar(Field, Field)instead.- 3.14.0 - [#8381] [#10641] - UseDSL.toChar(Field, Field)instead.- 3.14.0 - [#8381] [#10641] - UseDSL.toChar(Field, Field)instead.- 3.11.0 - [#7375] - This type is part of jOOQ's internal API. Do not reference this type directly from client code. Referencing this type before theSQLDataTypeclass has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataTypeinstead.- [#12420] - 3.16.0 - Use actualOIDcolumn references in jOOQ-meta, instead.- 3.11.0 - [#7375] - This type is part of jOOQ's internal API. Do not reference this type directly from client code. Referencing this type before theSQLDataTypeclass has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataTypeinstead.- 3.15.0 - [#10796] - This class will be removed, soon, no more vendor specific DSL API will be added.- 3.11.0 - [#7375] - This type is part of jOOQ's internal API. Do not reference this type directly from client code. Referencing this type before theSQLDataTypeclass has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataTypeinstead.- 3.11.0 - [#7375] - This type is part of jOOQ's internal API. Do not reference this type directly from client code. Referencing this type before theSQLDataTypeclass has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataTypeinstead.- 3.11.0 - [#7375] - This type is part of jOOQ's internal API. Do not reference this type directly from client code. Referencing this type before theSQLDataTypeclass has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataTypeinstead.- 3.15.0 - [#10796] - This class will be removed, soon, no more vendor specific DSL API will be added.- 3.11.0 - [#7375] - This type is part of jOOQ's internal API. Do not reference this type directly from client code. Referencing this type before theSQLDataTypeclass has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataTypeinstead.- 3.11.0 - [#7375] - This type is part of jOOQ's internal API. Do not reference this type directly from client code. Referencing this type before theSQLDataTypeclass has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataTypeinstead.- 3.15.0 - [#10796] - This class will be removed, soon, no more vendor specific DSL API will be added.- 3.11.0 - [#7375] - This type is part of jOOQ's internal API. Do not reference this type directly from client code. Referencing this type before theSQLDataTypeclass has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataTypeinstead.- 3.11.0 - [#7375] - This type is part of jOOQ's internal API. Do not reference this type directly from client code. Referencing this type before theSQLDataTypeclass has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataTypeinstead.- 3.15.0 - [#10796] - This class will be removed, soon, no more vendor specific DSL API will be added.- 3.11.0 - [#7375] - This type is part of jOOQ's internal API. Do not reference this type directly from client code. Referencing this type before theSQLDataTypeclass has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataTypeinstead.- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directly- 3.10 - [#6427] - This synthetic clause is no longer supported, useWindowPartitionByStep.partitionBy(GroupField...)instead, or omit the clause entirely.- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directly- 3.10 - [#6427] - This synthetic clause is no longer supported, useWindowSpecificationPartitionByStep.partitionBy(GroupField...)instead, or omit the clause entirely.- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaWithStep.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaWithStep.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaWithStep.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaWithStep.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaWithStep.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaWithStep.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaWithStep.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaWithStep.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaWithStep.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaWithStep.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaWithStep.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaWithStep.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaWithStep.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaWithStep.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaWithStep.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaWithStep.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaWithStep.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaWithStep.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaWithStep.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaWithStep.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaWithStep.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaWithStep.mergeInto(Table)- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.
-
Deprecated InterfacesInterfaceDescription- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directly
Referencing
XYZ*Steptypes directly from client codeIt is usually not recommended to reference any
XYZ*Steptypes 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*Steptypes 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 directlyReferencing
XYZ*Steptypes directly from client codeIt is usually not recommended to reference any
XYZ*Steptypes 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*Steptypes 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 directlyReferencing
XYZ*Steptypes directly from client codeIt is usually not recommended to reference any
XYZ*Steptypes 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*Steptypes 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 directlyReferencing
XYZ*Steptypes directly from client codeIt is usually not recommended to reference any
XYZ*Steptypes 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*Steptypes 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 directlyReferencing
XYZ*Steptypes directly from client codeIt is usually not recommended to reference any
XYZ*Steptypes 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*Steptypes 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 directlyReferencing
XYZ*Steptypes directly from client codeIt is usually not recommended to reference any
XYZ*Steptypes 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*Steptypes 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 directlyReferencing
XYZ*Steptypes directly from client codeIt is usually not recommended to reference any
XYZ*Steptypes 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*Steptypes 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 directlyReferencing
XYZ*Steptypes directly from client codeIt is usually not recommended to reference any
XYZ*Steptypes 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*Steptypes 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 directlyReferencing
XYZ*Steptypes directly from client codeIt is usually not recommended to reference any
XYZ*Steptypes 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*Steptypes 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 directlyReferencing
XYZ*Steptypes directly from client codeIt is usually not recommended to reference any
XYZ*Steptypes 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*Steptypes 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 directlyReferencing
XYZ*Steptypes directly from client codeIt is usually not recommended to reference any
XYZ*Steptypes 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*Steptypes 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 directlyReferencing
XYZ*Steptypes directly from client codeIt is usually not recommended to reference any
XYZ*Steptypes 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*Steptypes 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 directlyReferencing
XYZ*Steptypes directly from client codeIt is usually not recommended to reference any
XYZ*Steptypes 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*Steptypes 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 directlyReferencing
XYZ*Steptypes directly from client codeIt is usually not recommended to reference any
XYZ*Steptypes 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*Steptypes 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 directlyReferencing
XYZ*Steptypes directly from client codeIt is usually not recommended to reference any
XYZ*Steptypes 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*Steptypes 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 directlyReferencing
XYZ*Steptypes directly from client codeIt is usually not recommended to reference any
XYZ*Steptypes 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*Steptypes 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 directlyReferencing
XYZ*Steptypes directly from client codeIt is usually not recommended to reference any
XYZ*Steptypes 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*Steptypes 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 directlyReferencing
XYZ*Steptypes directly from client codeIt is usually not recommended to reference any
XYZ*Steptypes 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*Steptypes 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 directlyReferencing
XYZ*Steptypes directly from client codeIt is usually not recommended to reference any
XYZ*Steptypes 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*Steptypes 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 directlyReferencing
XYZ*Steptypes directly from client codeIt is usually not recommended to reference any
XYZ*Steptypes 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*Steptypes 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 directlyReferencing
XYZ*Steptypes directly from client codeIt is usually not recommended to reference any
XYZ*Steptypes 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*Steptypes 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] - UseTableElementinstead.- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directlyReferencing
XYZ*Steptypes directly from client codeIt is usually not recommended to reference any
XYZ*Steptypes 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*Steptypes 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, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- 3.15.0 - [#11902] - UseIterable.forEach(Consumer)based methods, instead.- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directlyReferencing
XYZ*Steptypes directly from client codeIt is usually not recommended to reference any
XYZ*Steptypes 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*Steptypes 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 directlyReferencing
XYZ*Steptypes directly from client codeIt is usually not recommended to reference any
XYZ*Steptypes 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*Steptypes 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 ClassesClassDescription- [#6875] [#7158] - 3.11.0 - Please re-generate your code- 3.15.0 - [#11505] - Use
Converter.ofNullable(Class, Class, Function, Function)instead, e.g.Converter.ofNullable(Date.class, LocalDate.class, Date::toLocalDate, Date::valueOf).- 3.17.0 - [#13542] - This class is no longer needed. Implement theDiagnosticsListenerSPI directly, instead.- 3.17.0 - [#13542] - This class is no longer needed. Implement theExecuteListenerSPI directly, instead.- 3.17.0 - [#13542] - This class is no longer needed. Implement theMigrationListenerSPI directly, instead.- 3.17.0 - [#13542] - This class is no longer needed. Implement theParseListenerSPI directly, instead.- 3.17.0 - [#13542] - This class is no longer needed. Implement theRecordListenerSPI directly, instead.- 3.17.0 - [#13542] - This class is no longer needed. Implement theTransactionListenerSPI directly, instead.- 3.17.0 - [#13542] - This class is no longer needed. Implement theVisitListenerSPI directly, instead.- 3.15.0 - [#11505] - UseConverter.ofNullable(Class, Class, Function, Function)instead, e.g.Converter.ofNullable(Timestamp.class, LocalDateTime.class, Timestamp::toLocalDateTime, Timestamp::valueOf).- 3.15.0 - [#11505] - UseConverter.ofNullable(Class, Class, Function, Function)instead, e.g.Converter.ofNullable(Time.class, LocalTime.class, Time::toLocalTime, Time::valueOf).- 2.0.5 - Use runtime configurationSettingsinstead- 3.15.0 - [#11898] This class will be removed in the future. Do not reuse. Data type conversion happens using internalConverterimplementations, orConverterProviderprovided ones, or implementations attached to fields via generated code, or viaField.convert(Converter), orDataType.asConvertedDataType(Converter).- 3.15.0 - [#11618] - This type is no longer used by jOOQ and will be removed in the future.- 3.15.0 - [#11618] - This type is no longer used by jOOQ and will be removed in the future.- 3.15.0 - [#11618] - This type is no longer used by jOOQ and will be removed in the future.- 3.11.0 - [#7375] - This type is part of jOOQ's internal API. Do not reference this type directly from client code. Referencing this type before theSQLDataTypeclass has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataTypeinstead.- 3.15.0 - [#10796] - This class will be removed, soon, no more vendor specific DSL API will be added.- 3.11.0 - [#7375] - This type is part of jOOQ's internal API. Do not reference this type directly from client code. Referencing this type before theSQLDataTypeclass has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataTypeinstead.- 3.15.0 - [#10796] - This class will be removed, soon, no more vendor specific DSL API will be added.- 3.11.0 - [#7375] - This type is part of jOOQ's internal API. Do not reference this type directly from client code. Referencing this type before theSQLDataTypeclass has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataTypeinstead.- 3.11.0 - [#7375] - This type is part of jOOQ's internal API. Do not reference this type directly from client code. Referencing this type before theSQLDataTypeclass has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataTypeinstead.- 3.11.0 - [#7375] - This type is part of jOOQ's internal API. Do not reference this type directly from client code. Referencing this type before theSQLDataTypeclass has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataTypeinstead.- 3.11.0 - [#7375] - This type is part of jOOQ's internal API. Do not reference this type directly from client code. Referencing this type before theSQLDataTypeclass has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataTypeinstead.- 3.11.0 - [#7375] - This type is part of jOOQ's internal API. Do not reference this type directly from client code. Referencing this type before theSQLDataTypeclass has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataTypeinstead.- 3.13.0 - [#9403] - This dialect is hardly used by anyone with jOOQ or without jOOQ and will be removed in the near future.- 3.11.0 - [#7375] - This type is part of jOOQ's internal API. Do not reference this type directly from client code. Referencing this type before theSQLDataTypeclass has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataTypeinstead.- 3.15.0 - [#10796] - This class will be removed, soon, no more vendor specific DSL API will be added.- 3.11.0 - [#7375] - This type is part of jOOQ's internal API. Do not reference this type directly from client code. Referencing this type before theSQLDataTypeclass has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataTypeinstead.- 3.15.0 - [#10796] - This class will be removed, soon, no more vendor specific DSL API will be added.- 3.11.0 - [#7375] - This type is part of jOOQ's internal API. Do not reference this type directly from client code. Referencing this type before theSQLDataTypeclass has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataTypeinstead.- 3.11.0 - [#7375] - This type is part of jOOQ's internal API. Do not reference this type directly from client code. Referencing this type before theSQLDataTypeclass has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataTypeinstead.- 3.15.0 - [#10796] - This class will be removed, soon, no more vendor specific DSL API will be added.- 3.11.0 - [#7375] - This type is part of jOOQ's internal API. Do not reference this type directly from client code. Referencing this type before theSQLDataTypeclass has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataTypeinstead.- 3.15.0 - [#10796] - This class will be removed, soon, no more vendor specific DSL API will be added.- 3.11.0 - [#7375] - This type is part of jOOQ's internal API. Do not reference this type directly from client code. Referencing this type before theSQLDataTypeclass has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataTypeinstead.- 3.15.0 - [#10796] - This class will be removed, soon, no more vendor specific DSL API will be added.- 3.11.0 - [#7375] - This type is part of jOOQ's internal API. Do not reference this type directly from client code. Referencing this type before theSQLDataTypeclass has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataTypeinstead.- 3.15.0 - [#10796] - This class will be removed, soon, no more vendor specific DSL API will be added.- 3.11.0 - [#7375] - This type is part of jOOQ's internal API. Do not reference this type directly from client code. Referencing this type before theSQLDataTypeclass has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataTypeinstead.- 3.11.0 - [#7375] - This type is part of jOOQ's internal API. Do not reference this type directly from client code. Referencing this type before theSQLDataTypeclass has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataTypeinstead.- 3.15.0 - [#10796] - This class will be removed, soon, no more vendor specific DSL API will be added.- 3.11.0 - [#7375] - This type is part of jOOQ's internal API. Do not reference this type directly from client code. Referencing this type before theSQLDataTypeclass has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataTypeinstead.- 3.15.0 - [#10796] - This class will be removed, soon, no more vendor specific DSL API will be added.- 3.8.0 - [#4550] Do not reference this type directly.- 3.11.0 - [#7375] - This type is part of jOOQ's internal API. Do not reference this type directly from client code. Referencing this type before theSQLDataTypeclass has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataTypeinstead.- 3.11.0 - [#7375] - This type is part of jOOQ's internal API. Do not reference this type directly from client code. Referencing this type before theSQLDataTypeclass has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataTypeinstead.- 3.11.0 - [#7375] - This type is part of jOOQ's internal API. Do not reference this type directly from client code. Referencing this type before theSQLDataTypeclass has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataTypeinstead.- 3.11.0 - [#7375] - This type is part of jOOQ's internal API. Do not reference this type directly from client code. Referencing this type before theSQLDataTypeclass has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataTypeinstead.- 3.11.0 - [#7375] - This type is part of jOOQ's internal API. Do not reference this type directly from client code. Referencing this type before theSQLDataTypeclass has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataTypeinstead.- 3.11.0 - [#7375] - This type is part of jOOQ's internal API. Do not reference this type directly from client code. Referencing this type before theSQLDataTypeclass has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataTypeinstead.- 3.15.0 - [#10796] - This class will be removed, soon, no more vendor specific DSL API will be added.- 3.11.0 - [#7375] - This type is part of jOOQ's internal API. Do not reference this type directly from client code. Referencing this type before theSQLDataTypeclass has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataTypeinstead.- 3.11.0 - [#7375] - This type is part of jOOQ's internal API. Do not reference this type directly from client code. Referencing this type before theSQLDataTypeclass has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataTypeinstead.- 3.11.0 - [#7375] - This type is part of jOOQ's internal API. Do not reference this type directly from client code. Referencing this type before theSQLDataTypeclass has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataTypeinstead.- 3.15.0 - [#10796] - This class will be removed, soon, no more vendor specific DSL API will be added.- 3.11.0 - [#7375] - This type is part of jOOQ's internal API. Do not reference this type directly from client code. Referencing this type before theSQLDataTypeclass has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataTypeinstead.- 3.11.0 - [#7375] - This type is part of jOOQ's internal API. Do not reference this type directly from client code. Referencing this type before theSQLDataTypeclass has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataTypeinstead.- 3.15.0 - [#10796] - This class will be removed, soon, no more vendor specific DSL API will be added.- 3.11.0 - [#7375] - This type is part of jOOQ's internal API. Do not reference this type directly from client code. Referencing this type before theSQLDataTypeclass has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataTypeinstead.- 3.11.0 - [#7375] - This type is part of jOOQ's internal API. Do not reference this type directly from client code. Referencing this type before theSQLDataTypeclass has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataTypeinstead.- 3.15.0 - [#10796] - This class will be removed, soon, no more vendor specific DSL API will be added.- 3.11.0 - [#7375] - This type is part of jOOQ's internal API. Do not reference this type directly from client code. Referencing this type before theSQLDataTypeclass has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataTypeinstead.
-
Deprecated Enum ClassesEnum ClassDescription- 3.11.0 - [#7258] - This part of the
VisitListenerSPI is deprecated. There are currently no plans of replacing it. Please get in touch if you think this functionality needs to be kept in one way or another: https://github.com/jOOQ/jOOQ/issues/7258- UseLog.Levelinstead
-
Deprecated Exception ClassesException ClassDescription- [#12425] - 3.16.0 - Missing implementations should be added as soon as possible!
-
Deprecated Annotation InterfacesAnnotation InterfaceDescription- 3.17.0 - [#13071] - Use
ApiStatus.Internalinstead.
-
Deprecated FieldsFieldDescription- use #expiration instead
-
Deprecated MethodsMethodDescription- 3.10 - [#6254] - This functionality is no longer supported and will be removed in 4.0- 3.10 - [#6254] - This functionality is no longer supported and will be removed in 4.0- 3.10 - [#6254] - This functionality is no longer supported and will be removed in 4.0- 3.10 - [#6254] - This functionality is no longer supported and will be removed in 4.0- 3.14.0 - [#9911] - This method is no longer supported.- 3.14.0 - [#9911] - This method is no longer supported.- 3.14.0 - [#9911] - This method is no longer supported.- 3.12.0 - [#5909] - Use
RenderKeywordCaseinstead.- 3.12.0 - [#5909] - UseRenderQuotedNamesandRenderNameCaseinstead.- 3.18.0 - [#14634] - The configuration of this transformation is deprecated. It will no longer be commercially available only, but apply also to the jOOQ Open Source Edition, when required.- 3.12.0 - [#5909] - UseRenderKeywordCaseinstead.- 3.12.0 - [#5909] - UseRenderQuotedNamesandRenderNameCaseinstead.- 3.18.0 - [#14634] - The configuration of this transformation is deprecated. It will no longer be commercially available only, but apply also to the jOOQ Open Source Edition, when required.- 3.12.0 - [#5909] - UseRenderKeywordCaseinstead.- 3.12.0 - [#5909] - UseRenderQuotedNamesandRenderNameCaseinstead.- 3.18.0 - [#14634] - The configuration of this transformation is deprecated. It will no longer be commercially available only, but apply also to the jOOQ Open Source Edition, when required.- 2.0.5 - UseConfiguration.settings()instead- [#10317] - 3.14.0 - Do not reuse this method. It will be removed without replacement.- [#10317] - 3.14.0 - Do not reuse this method. It will be removed without replacement.- 3.10.0 - [#4990] - UseDSL.keyword(String)instead.- 3.10.0 - [#4990] - Use any ofDSL.name(String),DSL.quotedName(String)orDSL.unquotedName(String)instead.- [#10689] - 3.14.0 - This converter does not work. Do not use this method, useConverters.identity(Class)instead.- [#10689] - 3.14.0 - This method does not provide any useful functionality and will be removed in the future.- 3.10 - [#6363] - UseCursor.fetchNext(int)instead.- 3.15.0 - [#11902] - UseIterable.forEach(Consumer)based methods, instead.- 3.15.0 - [#11902] - UseIterable.forEach(Consumer)based methods, instead.- 3.10 - [#6363] - UseCursor.fetchNext()instead.- 3.10 - [#6363] - UseCursor.fetchNext(RecordMapper)instead.- 3.10 - [#6363] - UseCursor.fetchNextInto(RecordHandler)instead.- 3.10 - [#6363] - UseCursor.fetchNextInto(Class)instead.- 3.10 - [#6363] - UseCursor.fetchNextInto(Table)instead.- 3.10 - [#6363] - UseCursor.fetchNextOptional()instead.- 3.10 - [#6363] - UseCursor.fetchNextOptional(RecordMapper)instead.- 3.10 - [#6363] - UseCursor.fetchNextOptionalInto(Class)instead.- 3.10 - [#6363] - UseCursor.fetchNextOptionalInto(Table)instead.- [#3852] - 3.8.0 - UseDataType.defaultValue(Field)instead.- [#6280] - 3.10 - Do not reuse this method. It will be completely internal with jOOQ 4.0- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#6280] - 3.10 - Do not reuse this method. It will be completely internal with jOOQ 4.0- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.11 - [#7538] - UseDSL.abs(Field)instead.- 3.11 - [#7538] - UseDSL.acos(Field)instead.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.13 - [#9407] - UseDSL.ascii(Field)instead.- 3.11 - [#7538] - UseDSL.asin(Field)instead.- 3.11 - [#7538] - UseDSL.atan(Field)instead.- 3.11 - [#7538] - UseDSL.atan2(Field, Number)instead.- 3.11 - [#7538] - UseDSL.atan2(Field, Field)instead.- 3.11 - [#7538] - UseDSL.avg(Field)instead.- 3.11 - [#7538] - UseDSL.avg(Field)instead.- 3.13 - [#9407] - UseDSL.bitLength(Field)instead.- 3.11 - [#7538] - UseDSL.ceil(Field)instead.- 3.13 - [#9407] - UseDSL.charLength(Field)instead.- 3.13 - [#9407] - UseDSL.coalesce(Field, Field...)instead.- 3.13 - [#9407] - UseDSL.coalesce(Object, Object...)instead.- 3.11 - [#7538] - UseDSL.cos(Field)instead.- 3.11 - [#7538] - UseDSL.cosh(Field)instead.- 3.11 - [#7538] - UseDSL.cot(Field)instead.- 3.11 - [#7538] - UseDSL.coth(Field)instead.- 3.11 - [#7538] - UseDSL.count(Field)instead.- 3.11 - [#7538] - UseDSL.countDistinct(Field)instead.- 3.11 - [#7538] - UseDSL.count(Field)instead.- 3.13 - [#9407] - UseDSL.decode(Field, Field, Field)instead.- 3.13 - [#9407] - UseDSL.decode(Field, Field, Field, Field...)instead.- 3.13 - [#9407] - UseDSL.decode(Object, Object, Object)instead.- 3.13 - [#9407] - UseDSL.decode(Object, Object, Object, Object...)instead.- 3.11 - [#7538] - UseDSL.deg(Field)instead.- 3.11 - [#7538] - UseDSL.exp(Field)instead.- 3.11 - [#7538] - UseDSL.extract(Field, DatePart)instead.- 3.11 - [#7538] - UseDSL.firstValue(Field)instead.- 3.11 - [#7538] - UseDSL.floor(Field)instead.- 3.11 - [#7538] - UseDSL.greatest(Field, Field...)instead.- 3.11 - [#7538] - UseDSL.greatest(Field, Field...)instead.- 3.11 - [#7538] - UseDSL.lag(Field)instead.- 3.11 - [#7538] - UseDSL.lag(Field, int)instead.- 3.11 - [#7538] - UseDSL.lag(Field, int, Field)instead.- 3.11 - [#7538] - UseDSL.lag(Field, int, Object)instead.- 3.11 - [#7538] - UseDSL.lastValue(Field)instead.- 3.11 - [#7538] - UseDSL.lead(Field)instead.- 3.11 - [#7538] - UseDSL.lead(Field, int)instead.- 3.11 - [#7538] - UseDSL.lead(Field, int, Field)instead.- 3.11 - [#7538] - UseDSL.lead(Field, int, Object)instead.- 3.11 - [#7538] - UseDSL.least(Field, Field...)instead.- 3.11 - [#7538] - UseDSL.least(Field, Field...)instead.- 3.13 - [#9407] - UseDSL.length(Field)instead.- 3.11 - [#7538] - UseDSL.ln(Field)instead.- 3.11 - [#7538] - UseDSL.log(Field, int)instead.- 3.13 - [#9407] - UseDSL.lower(Field)instead.- 3.13 - [#9407] - UseDSL.lpad(Field, int)instead.- 3.13 - [#9407] - UseDSL.lpad(Field, int, char)instead.- 3.13 - [#9407] - UseDSL.lpad(Field, Field)instead.- 3.13 - [#9407] - UseDSL.lpad(Field, Field, Field)instead.- 3.13 - [#9407] - UseDSL.ltrim(Field)instead.- 3.11 - [#7538] - UseDSL.max(Field)instead.- 3.11 - [#7538] - UseDSL.max(Field)instead.- 3.11 - [#7538] - UseDSL.median(Field)instead.- 3.11 - [#7538] - UseDSL.min(Field)instead.- 3.11 - [#7538] - UseDSL.min(Field)instead.- 3.13 - [#9407] - UseDSL.nullif(Field, Field)instead.- 3.13 - [#9407] - UseDSL.nullif(Field, Object)instead.- 3.13 - [#9407] - UseDSL.nvl(Field, Field)instead.- 3.13 - [#9407] - UseDSL.nvl(Field, Object)instead.- 3.13 - [#9407] - UseDSL.nvl2(Field, Field, Field)instead.- 3.13 - [#9407] - UseDSL.nvl2(Field, Object, Object)instead.- 3.13 - [#9407] - UseDSL.octetLength(Field)instead.- 3.13 - [#9407] - UseDSL.position(Field, String)instead.- 3.13 - [#9407] - UseDSL.position(Field, Field)instead.- 3.11 - [#7538] - UseDSL.rad(Field)instead.- 3.13 - [#9407] - UseDSL.repeat(Field, int)instead.- 3.13 - [#9407] - UseDSL.repeat(Field, Field)instead.- 3.13 - [#9407] - UseDSL.replace(Field, String)instead.- 3.13 - [#9407] - UseDSL.replace(Field, String, String)instead.- 3.13 - [#9407] - UseDSL.replace(Field, Field)instead.- 3.13 - [#9407] - UseDSL.replace(Field, Field, Field)instead.- 3.11 - [#7538] - UseDSL.round(Field)instead.- 3.11 - [#7538] - UseDSL.round(Field, int)instead.- 3.13 - [#9407] - UseDSL.rpad(Field, int)instead.- 3.13 - [#9407] - UseDSL.rpad(Field, int, char)instead.- 3.13 - [#9407] - UseDSL.rpad(Field, Field)instead.- 3.13 - [#9407] - UseDSL.rpad(Field, Field, Field)instead.- 3.13 - [#9407] - UseDSL.rtrim(Field)instead.- 3.11 - [#7538] - UseDSL.sign(Field)instead.- 3.11 - [#7538] - UseDSL.sin(Field)instead.- 3.11 - [#7538] - UseDSL.sinh(Field)instead.- 3.11 - [#7538] - UseDSL.sqrt(Field)instead.- 3.11 - [#7538] - UseDSL.stddevPop(Field)instead.- 3.11 - [#7538] - UseDSL.stddevPop(Field)instead.- 3.11 - [#7538] - UseDSL.stddevSamp(Field)instead.- 3.11 - [#7538] - UseDSL.stddevSamp(Field)instead.- 3.13 - [#9407] - UseDSL.substring(Field, int)instead.- 3.13 - [#9407] - UseDSL.substring(Field, int, int)instead.- 3.13 - [#9407] - UseDSL.substring(Field, Field)instead.- 3.13 - [#9407] - UseDSL.substring(Field, Field, Field)instead.- 3.11 - [#7538] - UseDSL.sum(Field)instead.- 3.11 - [#7538] - UseDSL.sum(Field)instead.- 3.11 - [#7538] - UseDSL.tan(Field)instead.- 3.11 - [#7538] - UseDSL.tanh(Field)instead.- 3.13 - [#9407] - UseDSL.trim(Field)instead.- 3.13 - [#9407] - UseDSL.upper(Field)instead.- 3.11 - [#7538] - UseDSL.varPop(Field)instead.- 3.11 - [#7538] - UseDSL.varPop(Field)instead.- 3.11 - [#7538] - UseDSL.varSamp(Field)instead.- 3.11 - [#7538] - UseDSL.varSamp(Field)instead.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- [#6875] [#7158] - 3.11.0 - Please re-generate your code- [#6875] [#7158] - 3.11.0 - Please re-generate your code- [#6875] [#7158] - 3.11.0 - Please re-generate your code- [#6875] [#7158] - 3.11.0 - Please re-generate your code- [#6875] [#7158] - 3.11.0 - Please re-generate your code- [#6875] [#7158] - 3.11.0 - Please re-generate your code- Please, re-generate your routine code.- Please, re-generate your routine code.- Please, re-generate your routine code.- Please, re-generate your routine code.- Please, re-generate your routine code.- Please, re-generate your routine code.- Please, re-generate your routine code.- Please, re-generate your routine code.- Please, re-generate your routine code.- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDefaultDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDefaultDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDefaultDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDefaultDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDefaultDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDefaultDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDefaultDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDefaultDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDefaultDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDefaultDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDefaultDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDefaultDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDefaultDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDefaultDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDefaultDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDefaultDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDefaultDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDefaultDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDefaultDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDefaultDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDefaultDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDefaultDSLContext.mergeInto(Table)- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.11.0 - [#7483] - The (indirect) use of the internal static data type registry is not recommended.- [#7956] - 3.12.0 - UseDSL.groupConcat(Field)andGroupConcatSeparatorStep.separator(String)instead.- [#15196] - 3.19.0 - The semantics of theFieldarguments in this method is inconsistent with that of other overloads, such asDSL.jsonbObject(Field, Field), which can lead to subtle bugs. Please refrain from using this overload as it will be removed in the future. UseDSL.jsonObject(JSONEntry...)instead.- [#15196] - 3.19.0 - The semantics of theFieldarguments in this method is inconsistent with that of other overloads, such asDSL.jsonbObject(Field, Field), which can lead to subtle bugs. Please refrain from using this overload as it will be removed in the future. UseDSL.jsonObject(JSONEntry...)instead.- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSL.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSL.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSL.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSL.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSL.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSL.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSL.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSL.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSL.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSL.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSL.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSL.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSL.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSL.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSL.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSL.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSL.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSL.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSL.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSL.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSL.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSL.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSL.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSL.mergeInto(Table)- [#11092] - 3.15.0 - This method will be removed without public replacement.- [#11092] - 3.15.0 - This method will be removed without public replacement.- [#11092] - 3.15.0 - This method will be removed without public replacement.- [#11092] - 3.15.0 - This method will be removed without public replacement.- [#11092] - 3.15.0 - This method will be removed without public replacement.- [#11092] - 3.15.0 - This method will be removed without public replacement.- [#11092] - 3.15.0 - This method will be removed without public replacement.- [#11812] - 3.15.0 - UseRow1as aSelectFielddirectly, instead.- [#11812] - 3.15.0 - UseRow10as aSelectFielddirectly, instead.- [#11812] - 3.15.0 - UseRow11as aSelectFielddirectly, instead.- [#11812] - 3.15.0 - UseRow12as aSelectFielddirectly, instead.- [#11812] - 3.15.0 - UseRow13as aSelectFielddirectly, instead.- [#11812] - 3.15.0 - UseRow14as aSelectFielddirectly, instead.- [#11812] - 3.15.0 - UseRow15as aSelectFielddirectly, instead.- [#11812] - 3.15.0 - UseRow16as aSelectFielddirectly, instead.- [#11812] - 3.15.0 - UseRow17as aSelectFielddirectly, instead.- [#11812] - 3.15.0 - UseRow18as aSelectFielddirectly, instead.- [#11812] - 3.15.0 - UseRow19as aSelectFielddirectly, instead.- [#11812] - 3.15.0 - UseRow2as aSelectFielddirectly, instead.- [#11812] - 3.15.0 - UseRow20as aSelectFielddirectly, instead.- [#11812] - 3.15.0 - UseRow21as aSelectFielddirectly, instead.- [#11812] - 3.15.0 - UseRow22as aSelectFielddirectly, instead.- [#11812] - 3.15.0 - UseRow3as aSelectFielddirectly, instead.- [#11812] - 3.15.0 - UseRow4as aSelectFielddirectly, instead.- [#11812] - 3.15.0 - UseRow5as aSelectFielddirectly, instead.- [#11812] - 3.15.0 - UseRow6as aSelectFielddirectly, instead.- [#11812] - 3.15.0 - UseRow7as aSelectFielddirectly, instead.- [#11812] - 3.15.0 - UseRow8as aSelectFielddirectly, instead.- [#11812] - 3.15.0 - UseRow9as aSelectFielddirectly, instead.- [#11812] - 3.15.0 - UseRowNas aSelectFielddirectly, instead.- 3.10 - [#6162] - UseDSL.sequence(Name)instead.- 3.10 - [#6162] - UseDSL.sequence(Name, Class)instead.- 3.10 - [#6162] - UseDSL.sequence(Name, DataType)instead.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#9404] - Please re-generate your code.org.jooq.impl.Internal.createForeignKey(UniqueKey<U>, Table<R>, String, TableField<R, ?>[], boolean) - 3.14.0 - [#9404] - Please re-generate your code.- 3.14.0 - [#9404] - Please re-generate your code.- 3.14.0 - [#9404] - Please re-generate your code.- 3.14.0 - [#9404] - Please re-generate your code.- 3.14.0 - [#9404] - Please re-generate your code.- [#11058] - 3.14.5 - Please re-generate your code.- [#12238] - 3.16.0 - Please re-generate your code.- 3.12.0 - [#8000] - UseUDTImpl.createField(Name, DataType, UDT)instead.- 3.12.0 - [#8000] - UseUDTImpl.createField(Name, DataType, UDT, String)instead.- 3.12.0 - [#8000] - UseUDTImpl.createField(Name, DataType, UDT, String, Binding)instead.- 3.12.0 - [#8000] - UseUDTImpl.createField(Name, DataType, UDT, String, Converter)instead.- 3.12.0 - [#8000] - UseUDTImpl.createField(Name, DataType, UDT, String, Converter, Binding)instead.- 3.14.0 - [#10010] - UseLoaderCSVStep.fieldsCorresponding()instead.- [#4859] - This is not supported for JSON loading.- 3.14.0 - [#10010] - UseLoaderJSONStep.fieldsCorresponding()instead.- 3.14.0 - [#4941] - UseLoaderListenerStep.onRowEnd(LoaderRowListener)instead.- 3.14.0 - [#10010] - UseLoaderRowsStep.fieldsCorresponding()instead.- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.12.0 - [#8163] - UsePivotForStep.for_(Field)instead.- 3.10 - [#6143] - UseQueries.queryStream()instead.- CallingQueryPartInternal.accept(Context)directly on aQueryPartis almost always a mistake. Instead,Context.visit(QueryPart)should be called.- CallingQueryPartInternal.rendersContent(Context)directly on aQueryPartis almost always a mistake.- 3.10 - [#6254] - This functionality is no longer supported and will be removed in 4.0- 3.10 - [#6254] - This functionality is no longer supported and will be removed in 4.0- 3.10 - [#6254] - This functionality is no longer supported and will be removed in 4.0- 3.10 - [#6254] - This functionality is no longer supported and will be removed in 4.0- 3.15.0 - [#11902] - UseIterable.forEach(Consumer)based methods, instead.- 3.15.0 - [#11902] - UseIterable.forEach(Consumer)based methods, instead.- 3.10 - [#6254] - This functionality is no longer supported and will be removed in 4.0- 3.10 - [#6254] - This functionality is no longer supported and will be removed in 4.0- 3.10 - [#6254] - This functionality is no longer supported and will be removed in 4.0- 3.10 - [#6254] - This functionality is no longer supported and will be removed in 4.0- [#7461] - SEEK BEFORE is not implemented correctly- [#7461] - SEEK BEFORE is not implemented correctly[#5218] - 3.14.0 - UseSelectQuery.setForLockModeNoWait()[#5218] - 3.14.0 - UseSelectQuery.setForLockModeOf(Collection)[#5218] - 3.14.0 - UseSelectQuery.setForLockModeOf(Field...)[#5218] - 3.14.0 - UseSelectQuery.setForLockModeOf(Table...)[#5218] - 3.14.0 - UseSelectQuery.setForLockModeSkipLocked()[#5218] - 3.14.0 - UseSelectQuery.setForLockModeWait(int)- [#7461] - SEEK BEFORE is not implemented correctly- [#7461] - SEEK BEFORE is not implemented correctly- [#7461] - SEEK BEFORE is not implemented correctly- [#7461] - SEEK BEFORE is not implemented correctly- [#7461] - SEEK BEFORE is not implemented correctly- [#7461] - SEEK BEFORE is not implemented correctly- [#7461] - SEEK BEFORE is not implemented correctly- [#7461] - SEEK BEFORE is not implemented correctly- [#7461] - SEEK BEFORE is not implemented correctly- [#7461] - SEEK BEFORE is not implemented correctly- [#7461] - SEEK BEFORE is not implemented correctly- [#7461] - SEEK BEFORE is not implemented correctly- [#7461] - SEEK BEFORE is not implemented correctly- [#7461] - SEEK BEFORE is not implemented correctly- [#7461] - SEEK BEFORE is not implemented correctly- [#7461] - SEEK BEFORE is not implemented correctly- [#7461] - SEEK BEFORE is not implemented correctly- [#7461] - SEEK BEFORE is not implemented correctly- [#7461] - SEEK BEFORE is not implemented correctly- [#7461] - SEEK BEFORE is not implemented correctly- [#7461] - SEEK BEFORE is not implemented correctly- [#7461] - SEEK BEFORE is not implemented correctly- [#7461] - SEEK BEFORE is not implemented correctly- [#7461] - SEEK BEFORE is not implemented correctly- [#7461] - SEEK BEFORE is not implemented correctly- [#7461] - SEEK BEFORE is not implemented correctly- [#7461] - SEEK BEFORE is not implemented correctly- [#7461] - SEEK BEFORE is not implemented correctly- [#7461] - SEEK BEFORE is not implemented correctly- [#7461] - SEEK BEFORE is not implemented correctly- [#7461] - SEEK BEFORE is not implemented correctly- [#7461] - SEEK BEFORE is not implemented correctly- [#7461] - SEEK BEFORE is not implemented correctly- [#7461] - SEEK BEFORE is not implemented correctly- [#7461] - SEEK BEFORE is not implemented correctly- [#7461] - SEEK BEFORE is not implemented correctly- [#7461] - SEEK BEFORE is not implemented correctly- [#7461] - SEEK BEFORE is not implemented correctly- [#7461] - SEEK BEFORE is not implemented correctly- [#7461] - SEEK BEFORE is not implemented correctly- [#7461] - SEEK BEFORE is not implemented correctly- [#7461] - SEEK BEFORE is not implemented correctly- [#7461] - SEEK BEFORE is not implemented correctly- [#7461] - SEEK BEFORE is not implemented correctly- [#7461] - SEEK BEFORE is not implemented correctly- [#7461] - SEEK BEFORE is not implemented correctly- [#9882] - 3.14.0 - UseSQLDialect.supportedBy(SQLDialect...)instead- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- UseMockFileDatabaseConfiguration.nullLiteral(String)instead.- Experimental: Do not use. Subject to change.[#78] 0.9.11, useReflect.onClass(Class)instead.[#78] 0.9.11, useReflect.onClass(String)instead.[#78] 0.9.11, useReflect.onClass(String, ClassLoader)instead.- 3.15.0 - [#8611] - This function has been removed from MySQL 8- 3.15.0 - [#8611] - This function has been removed from MySQL 8- 3.15.0 - [#8611] - This function has been removed from MySQL 8- 3.15.0 - [#8611] - This function has been removed from MySQL 8- 3.15.0 - [#8611] - This function has been removed from MySQL 8- 3.15.0 - [#8611] - This function has been removed from MySQL 8- 3.15.0 - [#8611] - This function has been removed from MySQL 8- 3.15.0 - [#8611] - This function has been removed from MySQL 8- 3.15.0 - [#8611] - This function has been removed from MySQL 8- 3.15.0 - [#8611] - This function has been removed from MySQL 8- 3.15.0 - [#8611] - This function has been removed from MySQL 8- 3.15.0 - [#8611] - This function has been removed from MySQL 8- 3.15.0 - [#8611] - This function has been removed from MySQL 8- 3.15.0 - [#8611] - This function has been removed from MySQL 8- 3.15.0 - [#8611] - This function has been removed from MySQL 8- 3.15.0 - [#8611] - This function has been removed from MySQL 8- 3.15.0 - [#8611] - This function has been removed from MySQL 8- 3.15.0 - [#8611] - This function has been removed from MySQL 8- 3.15.0 - [#8611] - This function has been removed from MySQL 8- 3.15.0 - [#8611] - This function has been removed from MySQL 8- 3.15.0 - [#8611] - This function has been removed from MySQL 8- 3.15.0 - [#12099] - MySQL 8.0.20 has deprecated this clause and replaced it by something new, which we'll support soon, see https://dev.mysql.com/doc/refman/8.0/en/insert-on-duplicate.html/ and https://github.com/jOOQ/jOOQ/issues/12099- 3.14.0 - [#8381] [#10641] - UseDSL.toChar(Field, Field)instead.- 3.14.0 - [#8381] [#10641] - UseDSL.toChar(Field, Field)instead.- 3.14.0 - [#8381] [#10641] - UseDSL.toChar(Field, Field)instead.- 3.14.0 - [#8381] [#10641] - UseDSL.toChar(Field, Field)instead.- 3.14.0 - [#8381] [#10641] - UseDSL.toChar(Field, Field)instead.- 3.14.0 - [#8381] [#10641] - UseDSL.toChar(Field, Field)instead.- 3.16.0 - [#14388] - UseDSL.arrayPrepend(Field, Field)instead.- 3.16.0 - [#14388] - Useinstead.invalid @link
DSL#arrayPrepend(Field, Object)- 3.16.0 - [#14388] - Useinstead.invalid @link
DSL#arrayPrepend(Object[], Field)- 3.16.0 - [#14388] - UseDSL.arrayAppend(Object[], Object)instead.- 3.16.0 - [#14388] - UseDSL.arrayConcat(Field, Field)instead.- 3.16.0 - [#14388] - UseDSL.arrayConcat(Field, Object[])instead.- 3.16.0 - [#14388] - UseDSL.arrayConcat(Object[], Field)instead.- 3.16.0 - [#14388] - UseDSL.arrayConcat(Object[], Object[])instead.- 3.16.0 - [#14352] - UseDSL.arrayOverlap(Field, Field)instead.- 3.16.0 - [#14352] - UseDSL.arrayOverlap(Field, Object[])instead.- 3.16.0 - [#14352] - UseDSL.arrayOverlap(Object[], Field)instead.- 3.16.0 - [#14352] - UseDSL.arrayOverlap(Object[], Object[])instead.- 3.16.0 - [#14388] - UseDSL.arrayPrepend(Field, Field)instead.- 3.16.0 - [#14388] - UseDSL.arrayPrepend(Field, Object[])instead.- 3.16.0 - [#14388] - UseDSL.arrayPrepend(Object, Field)instead.- 3.16.0 - [#14388] - UseDSL.arrayPrepend(Object, Object[])instead.- 3.16.0 - [#14388] - UseDSL.arrayConcat(Field, Field)instead.- 3.16.0 - [#14388] - Useinstead.invalid @link
DSL#arrayConcat(Field, Object)- 3.16.0 - [#14388] - UseDSL.arrayConcat(Object[], Field)instead.- 3.16.0 - [#14388] - Useinstead.invalid @link
DSL#arrayConcat(Object[], Object)- 3.18.0 - [#11981] - UseDSL.arrayReplace(Field, Field, Field)instead.- 3.18.0 - [#11981] - UseDSL.arrayReplace(Field, Field, Field)instead.- 3.18.0 - [#11981] - UseDSL.arrayReplace(Field, Field, Field)instead.- 3.18.0 - [#11981] - UseDSL.arrayReplace(Object[], Object, Object)instead.- [#12420] - 3.16.0 - Use actualOIDcolumn references in jOOQ-meta, instead.- 3.10 - [#6427] - This synthetic clause is no longer supported, useWindowPartitionByStep.partitionBy(GroupField...)instead, or omit the clause entirely.- 3.10 - [#6427] - This synthetic clause is no longer supported, useWindowSpecificationPartitionByStep.partitionBy(GroupField...)instead, or omit the clause entirely.- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaWithStep.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaWithStep.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaWithStep.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaWithStep.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaWithStep.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaWithStep.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaWithStep.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaWithStep.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaWithStep.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaWithStep.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaWithStep.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaWithStep.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaWithStep.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaWithStep.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaWithStep.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaWithStep.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaWithStep.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaWithStep.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaWithStep.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaWithStep.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaWithStep.mergeInto(Table)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaWithStep.mergeInto(Table)- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.- 3.14.0 - [#10156] - These methods will be removed without replacement from a future jOOQ. They offer convenience that is unidiomatic for jOOQ's DSL, without offering functionality that would not be possible otherwise - yet they add complexity in jOOQ's internals.
-
Deprecated ConstructorsConstructorDescription- 3.10 - [#5996] - Use
CustomTable(Name)instead.- 3.10 - [#5996] - UseCustomTable(Name, Schema)instead.- 3.11 - [#6631] - UseDefaultBinding.binding(Converter)instead.- [#11058] - 3.14.5 - Please re-generate your code.- [#11058] - 3.14.5 - Please re-generate your code.- 3.10 - [#5996] - UseTableImpl(Name)instead (or re-generated your code).- 3.10 - [#5996] - UseTableImpl(Name, Schema)instead (or re-generated your code).- 3.10 - [#5996] - UseTableImpl(Name, Schema, Table)instead (or re-generated your code).- 3.10 - [#5996] - UseTableImpl(Name, Schema, Table, Field[])instead (or re-generated your code).- 3.10 - [#5996] - UseTableImpl(Name, Schema, Table, Field[], String)instead (or re-generated your code).- 3.11 - [#7027] - UseTableImpl(Name, Schema, Table, Field[], Comment)instead.
-
Deprecated Enum ConstantsEnum ConstantDescription- [#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.
Referencing
XYZ*Steptypes directly from client codeIt is usually not recommended to reference any
XYZ*Steptypes 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*Steptypes directly: