Deprecated API
Contents
-
ElementDescription- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directly
Referencing
XYZ*Step
types directly from client codeIt is usually not recommended to reference any
XYZ*Step
types directly from client code, or assign them to local variables. When writing dynamic SQL, creating a statement's components dynamically, and passing them to the DSL API statically is usually a better choice. See the manual's section about dynamic SQL for details: https://www.jooq.org/doc/latest/manual/sql-building/dynamic-sql.Drawbacks of referencing the
XYZ*Step
types directly:- They're operating on mutable implementations (as of jOOQ 3.x)
- They're less composable and not easy to get right when dynamic SQL gets complex
- They're less readable
- They might have binary incompatible changes between minor releases
- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directlyReferencing
XYZ*Step
types directly from client codeIt is usually not recommended to reference any
XYZ*Step
types directly from client code, or assign them to local variables. When writing dynamic SQL, creating a statement's components dynamically, and passing them to the DSL API statically is usually a better choice. See the manual's section about dynamic SQL for details: https://www.jooq.org/doc/latest/manual/sql-building/dynamic-sql.Drawbacks of referencing the
XYZ*Step
types directly:- They're operating on mutable implementations (as of jOOQ 3.x)
- They're less composable and not easy to get right when dynamic SQL gets complex
- They're less readable
- They might have binary incompatible changes between minor releases
- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directlyReferencing
XYZ*Step
types directly from client codeIt is usually not recommended to reference any
XYZ*Step
types directly from client code, or assign them to local variables. When writing dynamic SQL, creating a statement's components dynamically, and passing them to the DSL API statically is usually a better choice. See the manual's section about dynamic SQL for details: https://www.jooq.org/doc/latest/manual/sql-building/dynamic-sql.Drawbacks of referencing the
XYZ*Step
types directly:- They're operating on mutable implementations (as of jOOQ 3.x)
- They're less composable and not easy to get right when dynamic SQL gets complex
- They're less readable
- They might have binary incompatible changes between minor releases
- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directlyReferencing
XYZ*Step
types directly from client codeIt is usually not recommended to reference any
XYZ*Step
types directly from client code, or assign them to local variables. When writing dynamic SQL, creating a statement's components dynamically, and passing them to the DSL API statically is usually a better choice. See the manual's section about dynamic SQL for details: https://www.jooq.org/doc/latest/manual/sql-building/dynamic-sql.Drawbacks of referencing the
XYZ*Step
types directly:- They're operating on mutable implementations (as of jOOQ 3.x)
- They're less composable and not easy to get right when dynamic SQL gets complex
- They're less readable
- They might have binary incompatible changes between minor releases
- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directly- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directlyReferencing
XYZ*Step
types directly from client codeIt is usually not recommended to reference any
XYZ*Step
types directly from client code, or assign them to local variables. When writing dynamic SQL, creating a statement's components dynamically, and passing them to the DSL API statically is usually a better choice. See the manual's section about dynamic SQL for details: https://www.jooq.org/doc/latest/manual/sql-building/dynamic-sql.Drawbacks of referencing the
XYZ*Step
types directly:- They're operating on mutable implementations (as of jOOQ 3.x)
- They're less composable and not easy to get right when dynamic SQL gets complex
- They're less readable
- They might have binary incompatible changes between minor releases
- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directlyReferencing
XYZ*Step
types directly from client codeIt is usually not recommended to reference any
XYZ*Step
types directly from client code, or assign them to local variables. When writing dynamic SQL, creating a statement's components dynamically, and passing them to the DSL API statically is usually a better choice. See the manual's section about dynamic SQL for details: https://www.jooq.org/doc/latest/manual/sql-building/dynamic-sql.Drawbacks of referencing the
XYZ*Step
types directly:- They're operating on mutable implementations (as of jOOQ 3.x)
- They're less composable and not easy to get right when dynamic SQL gets complex
- They're less readable
- They might have binary incompatible changes between minor releases
- 3.7.0 - [#4566] - UseList.toArray()
instead.- 3.7.0 - [#4566] - ArrayRecord already extendsList
. There is no need to call this any more.- 3.7.0 - [#4566] - UseList
methods instead.- 3.7.0 - [#4566] - UseList
methods instead.- 3.11.0 - [#7258] - This part of theVisitListener
SPI 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- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directlyReferencing
XYZ*Step
types directly from client codeIt is usually not recommended to reference any
XYZ*Step
types directly from client code, or assign them to local variables. When writing dynamic SQL, creating a statement's components dynamically, and passing them to the DSL API statically is usually a better choice. See the manual's section about dynamic SQL for details: https://www.jooq.org/doc/latest/manual/sql-building/dynamic-sql.Drawbacks of referencing the
XYZ*Step
types directly:- They're operating on mutable implementations (as of jOOQ 3.x)
- They're less composable and not easy to get right when dynamic SQL gets complex
- They're less readable
- They might have binary incompatible changes between minor releases
- 3.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*Step
types directly from client codeIt is usually not recommended to reference any
XYZ*Step
types directly from client code, or assign them to local variables. When writing dynamic SQL, creating a statement's components dynamically, and passing them to the DSL API statically is usually a better choice. See the manual's section about dynamic SQL for details: https://www.jooq.org/doc/latest/manual/sql-building/dynamic-sql.Drawbacks of referencing the
XYZ*Step
types directly:- They're operating on mutable implementations (as of jOOQ 3.x)
- They're less composable and not easy to get right when dynamic SQL gets complex
- They're less readable
- They might have binary incompatible changes between minor releases
- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directlyReferencing
XYZ*Step
types directly from client codeIt is usually not recommended to reference any
XYZ*Step
types directly from client code, or assign them to local variables. When writing dynamic SQL, creating a statement's components dynamically, and passing them to the DSL API statically is usually a better choice. See the manual's section about dynamic SQL for details: https://www.jooq.org/doc/latest/manual/sql-building/dynamic-sql.Drawbacks of referencing the
XYZ*Step
types directly:- They're operating on mutable implementations (as of jOOQ 3.x)
- They're less composable and not easy to get right when dynamic SQL gets complex
- They're less readable
- They might have binary incompatible changes between minor releases
- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directlyReferencing
XYZ*Step
types directly from client codeIt is usually not recommended to reference any
XYZ*Step
types directly from client code, or assign them to local variables. When writing dynamic SQL, creating a statement's components dynamically, and passing them to the DSL API statically is usually a better choice. See the manual's section about dynamic SQL for details: https://www.jooq.org/doc/latest/manual/sql-building/dynamic-sql.Drawbacks of referencing the
XYZ*Step
types directly:- They're operating on mutable implementations (as of jOOQ 3.x)
- They're less composable and not easy to get right when dynamic SQL gets complex
- They're less readable
- They might have binary incompatible changes between minor releases
- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directlyReferencing
XYZ*Step
types directly from client codeIt is usually not recommended to reference any
XYZ*Step
types directly from client code, or assign them to local variables. When writing dynamic SQL, creating a statement's components dynamically, and passing them to the DSL API statically is usually a better choice. See the manual's section about dynamic SQL for details: https://www.jooq.org/doc/latest/manual/sql-building/dynamic-sql.Drawbacks of referencing the
XYZ*Step
types directly:- They're operating on mutable implementations (as of jOOQ 3.x)
- They're less composable and not easy to get right when dynamic SQL gets complex
- They're less readable
- They might have binary incompatible changes between minor releases
- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directlyReferencing
XYZ*Step
types directly from client codeIt is usually not recommended to reference any
XYZ*Step
types directly from client code, or assign them to local variables. When writing dynamic SQL, creating a statement's components dynamically, and passing them to the DSL API statically is usually a better choice. See the manual's section about dynamic SQL for details: https://www.jooq.org/doc/latest/manual/sql-building/dynamic-sql.Drawbacks of referencing the
XYZ*Step
types directly:- They're operating on mutable implementations (as of jOOQ 3.x)
- They're less composable and not easy to get right when dynamic SQL gets complex
- They're less readable
- They might have binary incompatible changes between minor releases
- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directly- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directly- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directly- 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*Step
types directly from client codeIt is usually not recommended to reference any
XYZ*Step
types directly from client code, or assign them to local variables. When writing dynamic SQL, creating a statement's components dynamically, and passing them to the DSL API statically is usually a better choice. See the manual's section about dynamic SQL for details: https://www.jooq.org/doc/latest/manual/sql-building/dynamic-sql.Drawbacks of referencing the
XYZ*Step
types directly:- They're operating on mutable implementations (as of jOOQ 3.x)
- They're less composable and not easy to get right when dynamic SQL gets complex
- They're less readable
- They might have binary incompatible changes between minor releases
- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directlyReferencing
XYZ*Step
types directly from client codeIt is usually not recommended to reference any
XYZ*Step
types directly from client code, or assign them to local variables. When writing dynamic SQL, creating a statement's components dynamically, and passing them to the DSL API statically is usually a better choice. See the manual's section about dynamic SQL for details: https://www.jooq.org/doc/latest/manual/sql-building/dynamic-sql.Drawbacks of referencing the
XYZ*Step
types directly:- They're operating on mutable implementations (as of jOOQ 3.x)
- They're less composable and not easy to get right when dynamic SQL gets complex
- They're less readable
- They might have binary incompatible changes between minor releases
- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directlyReferencing
XYZ*Step
types directly from client codeIt is usually not recommended to reference any
XYZ*Step
types directly from client code, or assign them to local variables. When writing dynamic SQL, creating a statement's components dynamically, and passing them to the DSL API statically is usually a better choice. See the manual's section about dynamic SQL for details: https://www.jooq.org/doc/latest/manual/sql-building/dynamic-sql.Drawbacks of referencing the
XYZ*Step
types directly:- They're operating on mutable implementations (as of jOOQ 3.x)
- They're less composable and not easy to get right when dynamic SQL gets complex
- They're less readable
- They might have binary incompatible changes between minor releases
- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directlyReferencing
XYZ*Step
types directly from client codeIt is usually not recommended to reference any
XYZ*Step
types directly from client code, or assign them to local variables. When writing dynamic SQL, creating a statement's components dynamically, and passing them to the DSL API statically is usually a better choice. See the manual's section about dynamic SQL for details: https://www.jooq.org/doc/latest/manual/sql-building/dynamic-sql.Drawbacks of referencing the
XYZ*Step
types directly:- They're operating on mutable implementations (as of jOOQ 3.x)
- They're less composable and not easy to get right when dynamic SQL gets complex
- They're less readable
- They might have binary incompatible changes between minor releases
- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directlyReferencing
XYZ*Step
types directly from client codeIt is usually not recommended to reference any
XYZ*Step
types directly from client code, or assign them to local variables. When writing dynamic SQL, creating a statement's components dynamically, and passing them to the DSL API statically is usually a better choice. See the manual's section about dynamic SQL for details: https://www.jooq.org/doc/latest/manual/sql-building/dynamic-sql.Drawbacks of referencing the
XYZ*Step
types directly:- They're operating on mutable implementations (as of jOOQ 3.x)
- They're less composable and not easy to get right when dynamic SQL gets complex
- They're less readable
- They might have binary incompatible changes between minor releases
- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directlyReferencing
XYZ*Step
types directly from client codeIt is usually not recommended to reference any
XYZ*Step
types directly from client code, or assign them to local variables. When writing dynamic SQL, creating a statement's components dynamically, and passing them to the DSL API statically is usually a better choice. See the manual's section about dynamic SQL for details: https://www.jooq.org/doc/latest/manual/sql-building/dynamic-sql.Drawbacks of referencing the
XYZ*Step
types directly:- They're operating on mutable implementations (as of jOOQ 3.x)
- They're less composable and not easy to get right when dynamic SQL gets complex
- They're less readable
- They might have binary incompatible changes between minor releases
- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directly- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directlyReferencing
XYZ*Step
types directly from client codeIt is usually not recommended to reference any
XYZ*Step
types directly from client code, or assign them to local variables. When writing dynamic SQL, creating a statement's components dynamically, and passing them to the DSL API statically is usually a better choice. See the manual's section about dynamic SQL for details: https://www.jooq.org/doc/latest/manual/sql-building/dynamic-sql.Drawbacks of referencing the
XYZ*Step
types directly:- They're operating on mutable implementations (as of jOOQ 3.x)
- They're less composable and not easy to get right when dynamic SQL gets complex
- They're less readable
- They might have binary incompatible changes between minor releases
- [#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.org.jooq.DSLContext.createView(Name, BiFunction<? super Field<?>, ? super Integer, ? extends Name>)- 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.org.jooq.DSLContext.createViewIfNotExists(Table<?>, Function<? super Field<?>, ? extends Field<?>>)- 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*Step
types directly from client codeIt is usually not recommended to reference any
XYZ*Step
types directly from client code, or assign them to local variables. When writing dynamic SQL, creating a statement's components dynamically, and passing them to the DSL API statically is usually a better choice. See the manual's section about dynamic SQL for details: https://www.jooq.org/doc/latest/manual/sql-building/dynamic-sql.Drawbacks of referencing the
XYZ*Step
types directly:- They're operating on mutable implementations (as of jOOQ 3.x)
- They're less composable and not easy to get right when dynamic SQL gets complex
- They're less readable
- They might have binary incompatible changes between minor releases
- 3.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.- [#3843] - 3.6.0 - useDSL.field(Name, Class)
instead- [#3843] - 3.6.0 - useDSL.field(Name)
instead- [#3843] - 3.6.0 - useDSL.field(Name, DataType)
instead- 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.- [#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.- 3.6.0 - [#3854] - UseDSL.sql(String)
instead- 3.6.0 - [#3854] - UseDSL.sql(String, Object...)
instead- 3.6.0 - [#3854] - UseDSL.sql(String, QueryPart...)
instead- [#11812] - 3.15.0 - UseRow1
as aSelectField
directly, instead.- [#11812] - 3.15.0 - UseRow10
as aSelectField
directly, instead.- [#11812] - 3.15.0 - UseRow11
as aSelectField
directly, instead.- [#11812] - 3.15.0 - UseRow12
as aSelectField
directly, instead.- [#11812] - 3.15.0 - UseRow13
as aSelectField
directly, instead.- [#11812] - 3.15.0 - UseRow14
as aSelectField
directly, instead.org.jooq.impl.DSL.rowField(Row15<T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12, T13, T14, T15>)- [#11812] - 3.15.0 - UseRow15
as aSelectField
directly, instead.- [#11812] - 3.15.0 - UseRow16
as aSelectField
directly, instead.- [#11812] - 3.15.0 - UseRow17
as aSelectField
directly, instead.- [#11812] - 3.15.0 - UseRow18
as aSelectField
directly, instead.- [#11812] - 3.15.0 - UseRow19
as aSelectField
directly, instead.- [#11812] - 3.15.0 - UseRow2
as aSelectField
directly, instead.- [#11812] - 3.15.0 - UseRow20
as aSelectField
directly, instead.- [#11812] - 3.15.0 - UseRow21
as aSelectField
directly, instead.- [#11812] - 3.15.0 - UseRow22
as aSelectField
directly, instead.- [#11812] - 3.15.0 - UseRow3
as aSelectField
directly, instead.- [#11812] - 3.15.0 - UseRow4
as aSelectField
directly, instead.- [#11812] - 3.15.0 - UseRow5
as aSelectField
directly, instead.- [#11812] - 3.15.0 - UseRow6
as aSelectField
directly, instead.- [#11812] - 3.15.0 - UseRow7
as aSelectField
directly, instead.- [#11812] - 3.15.0 - UseRow8
as aSelectField
directly, instead.- [#11812] - 3.15.0 - UseRow9
as aSelectField
directly, instead.- [#11812] - 3.15.0 - UseRowN
as aSelectField
directly, instead.- [#3843] - 3.6.0 - useDSL.schema(Name)
instead- 3.10 - [#6162] - UseDSL.sequence(Name)
instead.- 3.10 - [#6162] - UseDSL.sequence(Name, Class)
instead.- 3.10 - [#6162] - UseDSL.sequence(Name, DataType)
instead.- [#3843] - 3.6.0 - useDSL.sequence(Name, Class)
instead- [#3843] - 3.6.0 - useDSL.sequence(Name)
instead- [#3843] - 3.6.0 - useDSL.sequence(Name, DataType)
instead- [#3843] - 3.6.0 - useDSL.table(Name)
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.- [#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)
org.jooq.MergeValuesStep15.values(T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12, T13, T14, T15)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - 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.6.0 - [#3879] - UseResult.intoArrays()
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*Step
types directly from client codeIt is usually not recommended to reference any
XYZ*Step
types directly from client code, or assign them to local variables. When writing dynamic SQL, creating a statement's components dynamically, and passing them to the DSL API statically is usually a better choice. See the manual's section about dynamic SQL for details: https://www.jooq.org/doc/latest/manual/sql-building/dynamic-sql.Drawbacks of referencing the
XYZ*Step
types directly:- They're operating on mutable implementations (as of jOOQ 3.x)
- They're less composable and not easy to get right when dynamic SQL gets complex
- They're less readable
- They might have binary incompatible changes between minor releases
- 2.0.5 - Use runtime configurationSettings
instead[#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.- [#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.org.jooq.TableLike.asTable(String, BiFunction<? super Field<?>, ? super Integer, ? extends String>)- 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 internalConverter
implementations, orConverterProvider
provided 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*Step
types directly from client codeIt is usually not recommended to reference any
XYZ*Step
types directly from client code, or assign them to local variables. When writing dynamic SQL, creating a statement's components dynamically, and passing them to the DSL API statically is usually a better choice. See the manual's section about dynamic SQL for details: https://www.jooq.org/doc/latest/manual/sql-building/dynamic-sql.Drawbacks of referencing the
XYZ*Step
types directly:- They're operating on mutable implementations (as of jOOQ 3.x)
- They're less composable and not easy to get right when dynamic SQL gets complex
- They're less readable
- They might have binary incompatible changes between minor releases
- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directly- 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 theSQLDataType
class has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataType
instead.- 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 theSQLDataType
class has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataType
instead.- 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 theSQLDataType
class has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataType
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 theSQLDataType
class has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataType
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 theSQLDataType
class has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataType
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 theSQLDataType
class has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataType
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 theSQLDataType
class has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataType
instead.- 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 theSQLDataType
class has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataType
instead.- 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 theSQLDataType
class has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataType
instead.- 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 theSQLDataType
class has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataType
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 theSQLDataType
class has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataType
instead.- 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 theSQLDataType
class has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataType
instead.- 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 theSQLDataType
class has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataType
instead.- 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 theSQLDataType
class has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataType
instead.- 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 theSQLDataType
class has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataType
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 theSQLDataType
class has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataType
instead.- 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 theSQLDataType
class has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataType
instead.- 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 theSQLDataType
class has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataType
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 theSQLDataType
class has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataType
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 theSQLDataType
class has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataType
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.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 theSQLDataType
class has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataType
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.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 theSQLDataType
class has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataType
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 theSQLDataType
class has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataType
instead.- 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 theSQLDataType
class has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataType
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 theSQLDataType
class has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataType
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 theSQLDataType
class has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataType
instead.- 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 theSQLDataType
class has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataType
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 theSQLDataType
class has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataType
instead.- 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 theSQLDataType
class has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataType
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 theSQLDataType
class has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataType
instead.- 3.15.0 - [#10796] - This class will be removed, soon, no more vendor specific DSL API will be added.- [#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(Field...)
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(Field...)
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.
-
InterfaceDescription- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directly
Referencing
XYZ*Step
types directly from client codeIt is usually not recommended to reference any
XYZ*Step
types directly from client code, or assign them to local variables. When writing dynamic SQL, creating a statement's components dynamically, and passing them to the DSL API statically is usually a better choice. See the manual's section about dynamic SQL for details: https://www.jooq.org/doc/latest/manual/sql-building/dynamic-sql.Drawbacks of referencing the
XYZ*Step
types directly:- They're operating on mutable implementations (as of jOOQ 3.x)
- They're less composable and not easy to get right when dynamic SQL gets complex
- They're less readable
- They might have binary incompatible changes between minor releases
- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directlyReferencing
XYZ*Step
types directly from client codeIt is usually not recommended to reference any
XYZ*Step
types directly from client code, or assign them to local variables. When writing dynamic SQL, creating a statement's components dynamically, and passing them to the DSL API statically is usually a better choice. See the manual's section about dynamic SQL for details: https://www.jooq.org/doc/latest/manual/sql-building/dynamic-sql.Drawbacks of referencing the
XYZ*Step
types directly:- They're operating on mutable implementations (as of jOOQ 3.x)
- They're less composable and not easy to get right when dynamic SQL gets complex
- They're less readable
- They might have binary incompatible changes between minor releases
- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directlyReferencing
XYZ*Step
types directly from client codeIt is usually not recommended to reference any
XYZ*Step
types directly from client code, or assign them to local variables. When writing dynamic SQL, creating a statement's components dynamically, and passing them to the DSL API statically is usually a better choice. See the manual's section about dynamic SQL for details: https://www.jooq.org/doc/latest/manual/sql-building/dynamic-sql.Drawbacks of referencing the
XYZ*Step
types directly:- They're operating on mutable implementations (as of jOOQ 3.x)
- They're less composable and not easy to get right when dynamic SQL gets complex
- They're less readable
- They might have binary incompatible changes between minor releases
- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directlyReferencing
XYZ*Step
types directly from client codeIt is usually not recommended to reference any
XYZ*Step
types directly from client code, or assign them to local variables. When writing dynamic SQL, creating a statement's components dynamically, and passing them to the DSL API statically is usually a better choice. See the manual's section about dynamic SQL for details: https://www.jooq.org/doc/latest/manual/sql-building/dynamic-sql.Drawbacks of referencing the
XYZ*Step
types directly:- They're operating on mutable implementations (as of jOOQ 3.x)
- They're less composable and not easy to get right when dynamic SQL gets complex
- They're less readable
- They might have binary incompatible changes between minor releases
- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directlyReferencing
XYZ*Step
types directly from client codeIt is usually not recommended to reference any
XYZ*Step
types directly from client code, or assign them to local variables. When writing dynamic SQL, creating a statement's components dynamically, and passing them to the DSL API statically is usually a better choice. See the manual's section about dynamic SQL for details: https://www.jooq.org/doc/latest/manual/sql-building/dynamic-sql.Drawbacks of referencing the
XYZ*Step
types directly:- They're operating on mutable implementations (as of jOOQ 3.x)
- They're less composable and not easy to get right when dynamic SQL gets complex
- They're less readable
- They might have binary incompatible changes between minor releases
- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directly- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directlyReferencing
XYZ*Step
types directly from client codeIt is usually not recommended to reference any
XYZ*Step
types directly from client code, or assign them to local variables. When writing dynamic SQL, creating a statement's components dynamically, and passing them to the DSL API statically is usually a better choice. See the manual's section about dynamic SQL for details: https://www.jooq.org/doc/latest/manual/sql-building/dynamic-sql.Drawbacks of referencing the
XYZ*Step
types directly:- They're operating on mutable implementations (as of jOOQ 3.x)
- They're less composable and not easy to get right when dynamic SQL gets complex
- They're less readable
- They might have binary incompatible changes between minor releases
- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directlyReferencing
XYZ*Step
types directly from client codeIt is usually not recommended to reference any
XYZ*Step
types directly from client code, or assign them to local variables. When writing dynamic SQL, creating a statement's components dynamically, and passing them to the DSL API statically is usually a better choice. See the manual's section about dynamic SQL for details: https://www.jooq.org/doc/latest/manual/sql-building/dynamic-sql.Drawbacks of referencing the
XYZ*Step
types directly:- They're operating on mutable implementations (as of jOOQ 3.x)
- They're less composable and not easy to get right when dynamic SQL gets complex
- They're less readable
- They might have binary incompatible changes between minor releases
- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directlyReferencing
XYZ*Step
types directly from client codeIt is usually not recommended to reference any
XYZ*Step
types directly from client code, or assign them to local variables. When writing dynamic SQL, creating a statement's components dynamically, and passing them to the DSL API statically is usually a better choice. See the manual's section about dynamic SQL for details: https://www.jooq.org/doc/latest/manual/sql-building/dynamic-sql.Drawbacks of referencing the
XYZ*Step
types directly:- They're operating on mutable implementations (as of jOOQ 3.x)
- They're less composable and not easy to get right when dynamic SQL gets complex
- They're less readable
- They might have binary incompatible changes between minor releases
- 2.6.0 [#1881] - This type will be removed from the public API, soon. Its methods will be pushed down into extending interfaces. Do not reference this type directly.- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directly- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directlyReferencing
XYZ*Step
types directly from client codeIt is usually not recommended to reference any
XYZ*Step
types directly from client code, or assign them to local variables. When writing dynamic SQL, creating a statement's components dynamically, and passing them to the DSL API statically is usually a better choice. See the manual's section about dynamic SQL for details: https://www.jooq.org/doc/latest/manual/sql-building/dynamic-sql.Drawbacks of referencing the
XYZ*Step
types directly:- They're operating on mutable implementations (as of jOOQ 3.x)
- They're less composable and not easy to get right when dynamic SQL gets complex
- They're less readable
- They might have binary incompatible changes between minor releases
- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directlyReferencing
XYZ*Step
types directly from client codeIt is usually not recommended to reference any
XYZ*Step
types directly from client code, or assign them to local variables. When writing dynamic SQL, creating a statement's components dynamically, and passing them to the DSL API statically is usually a better choice. See the manual's section about dynamic SQL for details: https://www.jooq.org/doc/latest/manual/sql-building/dynamic-sql.Drawbacks of referencing the
XYZ*Step
types directly:- They're operating on mutable implementations (as of jOOQ 3.x)
- They're less composable and not easy to get right when dynamic SQL gets complex
- They're less readable
- They might have binary incompatible changes between minor releases
- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directlyReferencing
XYZ*Step
types directly from client codeIt is usually not recommended to reference any
XYZ*Step
types directly from client code, or assign them to local variables. When writing dynamic SQL, creating a statement's components dynamically, and passing them to the DSL API statically is usually a better choice. See the manual's section about dynamic SQL for details: https://www.jooq.org/doc/latest/manual/sql-building/dynamic-sql.Drawbacks of referencing the
XYZ*Step
types directly:- They're operating on mutable implementations (as of jOOQ 3.x)
- They're less composable and not easy to get right when dynamic SQL gets complex
- They're less readable
- They might have binary incompatible changes between minor releases
- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directlyReferencing
XYZ*Step
types directly from client codeIt is usually not recommended to reference any
XYZ*Step
types directly from client code, or assign them to local variables. When writing dynamic SQL, creating a statement's components dynamically, and passing them to the DSL API statically is usually a better choice. See the manual's section about dynamic SQL for details: https://www.jooq.org/doc/latest/manual/sql-building/dynamic-sql.Drawbacks of referencing the
XYZ*Step
types directly:- They're operating on mutable implementations (as of jOOQ 3.x)
- They're less composable and not easy to get right when dynamic SQL gets complex
- They're less readable
- They might have binary incompatible changes between minor releases
- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directlyReferencing
XYZ*Step
types directly from client codeIt is usually not recommended to reference any
XYZ*Step
types directly from client code, or assign them to local variables. When writing dynamic SQL, creating a statement's components dynamically, and passing them to the DSL API statically is usually a better choice. See the manual's section about dynamic SQL for details: https://www.jooq.org/doc/latest/manual/sql-building/dynamic-sql.Drawbacks of referencing the
XYZ*Step
types directly:- They're operating on mutable implementations (as of jOOQ 3.x)
- They're less composable and not easy to get right when dynamic SQL gets complex
- They're less readable
- They might have binary incompatible changes between minor releases
- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directly- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directly- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directly- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directly- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directlyReferencing
XYZ*Step
types directly from client codeIt is usually not recommended to reference any
XYZ*Step
types directly from client code, or assign them to local variables. When writing dynamic SQL, creating a statement's components dynamically, and passing them to the DSL API statically is usually a better choice. See the manual's section about dynamic SQL for details: https://www.jooq.org/doc/latest/manual/sql-building/dynamic-sql.Drawbacks of referencing the
XYZ*Step
types directly:- They're operating on mutable implementations (as of jOOQ 3.x)
- They're less composable and not easy to get right when dynamic SQL gets complex
- They're less readable
- They might have binary incompatible changes between minor releases
- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directlyReferencing
XYZ*Step
types directly from client codeIt is usually not recommended to reference any
XYZ*Step
types directly from client code, or assign them to local variables. When writing dynamic SQL, creating a statement's components dynamically, and passing them to the DSL API statically is usually a better choice. See the manual's section about dynamic SQL for details: https://www.jooq.org/doc/latest/manual/sql-building/dynamic-sql.Drawbacks of referencing the
XYZ*Step
types directly:- They're operating on mutable implementations (as of jOOQ 3.x)
- They're less composable and not easy to get right when dynamic SQL gets complex
- They're less readable
- They might have binary incompatible changes between minor releases
- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directlyReferencing
XYZ*Step
types directly from client codeIt is usually not recommended to reference any
XYZ*Step
types directly from client code, or assign them to local variables. When writing dynamic SQL, creating a statement's components dynamically, and passing them to the DSL API statically is usually a better choice. See the manual's section about dynamic SQL for details: https://www.jooq.org/doc/latest/manual/sql-building/dynamic-sql.Drawbacks of referencing the
XYZ*Step
types directly:- They're operating on mutable implementations (as of jOOQ 3.x)
- They're less composable and not easy to get right when dynamic SQL gets complex
- They're less readable
- They might have binary incompatible changes between minor releases
- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directlyReferencing
XYZ*Step
types directly from client codeIt is usually not recommended to reference any
XYZ*Step
types directly from client code, or assign them to local variables. When writing dynamic SQL, creating a statement's components dynamically, and passing them to the DSL API statically is usually a better choice. See the manual's section about dynamic SQL for details: https://www.jooq.org/doc/latest/manual/sql-building/dynamic-sql.Drawbacks of referencing the
XYZ*Step
types directly:- They're operating on mutable implementations (as of jOOQ 3.x)
- They're less composable and not easy to get right when dynamic SQL gets complex
- They're less readable
- They might have binary incompatible changes between minor releases
- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directlyReferencing
XYZ*Step
types directly from client codeIt is usually not recommended to reference any
XYZ*Step
types directly from client code, or assign them to local variables. When writing dynamic SQL, creating a statement's components dynamically, and passing them to the DSL API statically is usually a better choice. See the manual's section about dynamic SQL for details: https://www.jooq.org/doc/latest/manual/sql-building/dynamic-sql.Drawbacks of referencing the
XYZ*Step
types directly:- They're operating on mutable implementations (as of jOOQ 3.x)
- They're less composable and not easy to get right when dynamic SQL gets complex
- They're less readable
- They might have binary incompatible changes between minor releases
- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directlyReferencing
XYZ*Step
types directly from client codeIt is usually not recommended to reference any
XYZ*Step
types directly from client code, or assign them to local variables. When writing dynamic SQL, creating a statement's components dynamically, and passing them to the DSL API statically is usually a better choice. See the manual's section about dynamic SQL for details: https://www.jooq.org/doc/latest/manual/sql-building/dynamic-sql.Drawbacks of referencing the
XYZ*Step
types directly:- They're operating on mutable implementations (as of jOOQ 3.x)
- They're less composable and not easy to get right when dynamic SQL gets complex
- They're less readable
- They might have binary incompatible changes between minor releases
- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directly- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directlyReferencing
XYZ*Step
types directly from client codeIt is usually not recommended to reference any
XYZ*Step
types directly from client code, or assign them to local variables. When writing dynamic SQL, creating a statement's components dynamically, and passing them to the DSL API statically is usually a better choice. See the manual's section about dynamic SQL for details: https://www.jooq.org/doc/latest/manual/sql-building/dynamic-sql.Drawbacks of referencing the
XYZ*Step
types directly:- They're operating on mutable implementations (as of jOOQ 3.x)
- They're less composable and not easy to get right when dynamic SQL gets complex
- They're less readable
- They might have binary incompatible changes between minor releases
- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directlyReferencing
XYZ*Step
types directly from client codeIt is usually not recommended to reference any
XYZ*Step
types directly from client code, or assign them to local variables. When writing dynamic SQL, creating a statement's components dynamically, and passing them to the DSL API statically is usually a better choice. See the manual's section about dynamic SQL for details: https://www.jooq.org/doc/latest/manual/sql-building/dynamic-sql.Drawbacks of referencing the
XYZ*Step
types directly:- They're operating on mutable implementations (as of jOOQ 3.x)
- They're less composable and not easy to get right when dynamic SQL gets complex
- They're less readable
- They might have binary incompatible changes between minor releases
- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directly- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directly- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - 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*Step
types directly from client codeIt is usually not recommended to reference any
XYZ*Step
types directly from client code, or assign them to local variables. When writing dynamic SQL, creating a statement's components dynamically, and passing them to the DSL API statically is usually a better choice. See the manual's section about dynamic SQL for details: https://www.jooq.org/doc/latest/manual/sql-building/dynamic-sql.Drawbacks of referencing the
XYZ*Step
types directly:- They're operating on mutable implementations (as of jOOQ 3.x)
- They're less composable and not easy to get right when dynamic SQL gets complex
- They're less readable
- They might have binary incompatible changes between minor releases
- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directlyReferencing
XYZ*Step
types directly from client codeIt is usually not recommended to reference any
XYZ*Step
types directly from client code, or assign them to local variables. When writing dynamic SQL, creating a statement's components dynamically, and passing them to the DSL API statically is usually a better choice. See the manual's section about dynamic SQL for details: https://www.jooq.org/doc/latest/manual/sql-building/dynamic-sql.Drawbacks of referencing the
XYZ*Step
types directly:- They're operating on mutable implementations (as of jOOQ 3.x)
- They're less composable and not easy to get right when dynamic SQL gets complex
- They're less readable
- They might have binary incompatible changes between minor releases
- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directly- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directly- [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directly
-
ClassDescription- [#6875] [#7158] - 3.11.0 - Please re-generate your code- 3.15.0 - [#11505] - Use
Converter.ofNullable(Class, Class, java.util.function.Function, java.util.function.Function)
instead, e.g.Converter.ofNullable(Date.class, LocalDate.class, Date::toLocalDate, Date::valueOf)
.- 3.15.0 - [#11505] - UseConverter.ofNullable(Class, Class, java.util.function.Function, java.util.function.Function)
instead, e.g.Converter.ofNullable(Timestamp.class, LocalDateTime.class, Timestamp::toLocalDateTime, Timestamp::valueOf)
.- 3.15.0 - [#11505] - UseConverter.ofNullable(Class, Class, java.util.function.Function, java.util.function.Function)
instead, e.g.Converter.ofNullable(Time.class, LocalTime.class, Time::toLocalTime, Time::valueOf)
.- 2.0.5 - Use runtime configurationSettings
instead- 3.15.0 - [#11898] This class will be removed in the future. Do not reuse. Data type conversion happens using internalConverter
implementations, orConverterProvider
provided 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 theSQLDataType
class has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataType
instead.- 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 theSQLDataType
class has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataType
instead.- 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 theSQLDataType
class has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataType
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 theSQLDataType
class has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataType
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 theSQLDataType
class has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataType
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 theSQLDataType
class has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataType
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 theSQLDataType
class has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataType
instead.- 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 theSQLDataType
class has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataType
instead.- 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 theSQLDataType
class has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataType
instead.- 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 theSQLDataType
class has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataType
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 theSQLDataType
class has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataType
instead.- 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 theSQLDataType
class has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataType
instead.- 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 theSQLDataType
class has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataType
instead.- 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 theSQLDataType
class has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataType
instead.- 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 theSQLDataType
class has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataType
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 theSQLDataType
class has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataType
instead.- 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 theSQLDataType
class has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataType
instead.- 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 theSQLDataType
class has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataType
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 theSQLDataType
class has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataType
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 theSQLDataType
class has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataType
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 theSQLDataType
class has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataType
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 theSQLDataType
class has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataType
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 theSQLDataType
class has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataType
instead.- 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 theSQLDataType
class has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataType
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 theSQLDataType
class has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataType
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 theSQLDataType
class has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataType
instead.- 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 theSQLDataType
class has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataType
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 theSQLDataType
class has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataType
instead.- 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 theSQLDataType
class has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataType
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 theSQLDataType
class has been initialised may lead to deadlocks! See https://github.com/jOOQ/jOOQ/issues/3777 for details.Use the corresponding
SQLDataType
instead.- 3.15.0 - [#10796] - This class will be removed, soon, no more vendor specific DSL API will be added.
-
Enum ClassDescription- 3.11.0 - [#7258] - This part of the
VisitListener
SPI 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.Level
instead
-
FieldDescription- use #expiration instead
-
MethodDescription- 3.7.0 - [#4566] - Use
List.toArray()
instead.- 3.7.0 - [#4566] - ArrayRecord already extendsList
. There is no need to call this any more.- 3.7.0 - [#4566] - UseList
methods instead.- 3.7.0 - [#4566] - UseList
methods instead.- 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] - UseRenderKeywordCase
instead.- 3.12.0 - [#5909] - UseRenderQuotedNames
andRenderNameCase
instead.- 3.12.0 - [#5909] - UseRenderKeywordCase
instead.- 3.12.0 - [#5909] - UseRenderQuotedNames
andRenderNameCase
instead.- 3.12.0 - [#5909] - UseRenderKeywordCase
instead.- 3.12.0 - [#5909] - UseRenderQuotedNames
andRenderNameCase
instead.- 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.org.jooq.DSLContext.createView(Name, BiFunction<? super Field<?>, ? super Integer, ? extends Name>)- 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.org.jooq.DSLContext.createViewIfNotExists(Table<?>, Function<? super Field<?>, ? extends Field<?>>)- 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.org.jooq.impl.AbstractRoutine.createParameter(String, DataType<T>, boolean, boolean, Binding<T, U>)- 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.- [#3843] - 3.6.0 - useDSL.field(Name, Class)
instead- [#3843] - 3.6.0 - useDSL.field(Name)
instead- [#3843] - 3.6.0 - useDSL.field(Name, DataType)
instead- 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.- [#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.- 3.6.0 - [#3854] - UseDSL.sql(String)
instead- 3.6.0 - [#3854] - UseDSL.sql(String, Object...)
instead- 3.6.0 - [#3854] - UseDSL.sql(String, QueryPart...)
instead- [#11812] - 3.15.0 - UseRow1
as aSelectField
directly, instead.- [#11812] - 3.15.0 - UseRow10
as aSelectField
directly, instead.- [#11812] - 3.15.0 - UseRow11
as aSelectField
directly, instead.- [#11812] - 3.15.0 - UseRow12
as aSelectField
directly, instead.- [#11812] - 3.15.0 - UseRow13
as aSelectField
directly, instead.- [#11812] - 3.15.0 - UseRow14
as aSelectField
directly, instead.org.jooq.impl.DSL.rowField(Row15<T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12, T13, T14, T15>)- [#11812] - 3.15.0 - UseRow15
as aSelectField
directly, instead.- [#11812] - 3.15.0 - UseRow16
as aSelectField
directly, instead.- [#11812] - 3.15.0 - UseRow17
as aSelectField
directly, instead.- [#11812] - 3.15.0 - UseRow18
as aSelectField
directly, instead.- [#11812] - 3.15.0 - UseRow19
as aSelectField
directly, instead.- [#11812] - 3.15.0 - UseRow2
as aSelectField
directly, instead.- [#11812] - 3.15.0 - UseRow20
as aSelectField
directly, instead.- [#11812] - 3.15.0 - UseRow21
as aSelectField
directly, instead.- [#11812] - 3.15.0 - UseRow22
as aSelectField
directly, instead.- [#11812] - 3.15.0 - UseRow3
as aSelectField
directly, instead.- [#11812] - 3.15.0 - UseRow4
as aSelectField
directly, instead.- [#11812] - 3.15.0 - UseRow5
as aSelectField
directly, instead.- [#11812] - 3.15.0 - UseRow6
as aSelectField
directly, instead.- [#11812] - 3.15.0 - UseRow7
as aSelectField
directly, instead.- [#11812] - 3.15.0 - UseRow8
as aSelectField
directly, instead.- [#11812] - 3.15.0 - UseRow9
as aSelectField
directly, instead.- [#11812] - 3.15.0 - UseRowN
as aSelectField
directly, instead.- [#3843] - 3.6.0 - useDSL.schema(Name)
instead- 3.10 - [#6162] - UseDSL.sequence(Name)
instead.- 3.10 - [#6162] - UseDSL.sequence(Name, Class)
instead.- 3.10 - [#6162] - UseDSL.sequence(Name, DataType)
instead.- [#3843] - 3.6.0 - useDSL.sequence(Name, Class)
instead- [#3843] - 3.6.0 - useDSL.sequence(Name)
instead- [#3843] - 3.6.0 - useDSL.sequence(Name, DataType)
instead- [#3843] - 3.6.0 - useDSL.table(Name)
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.- 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.- 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)
org.jooq.MergeValuesStep15.values(T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12, T13, T14, T15)- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
- [#10045] - 3.14.0 - 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 aQueryPart
is almost always a mistake. Instead,Context.visit(QueryPart)
should be called.- CallingQueryPartInternal.rendersContent(Context)
directly on aQueryPart
is 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.6.0 - [#3879] - UseResult.intoArrays()
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.org.jooq.TableLike.asTable(String, BiFunction<? super Field<?>, ? super Integer, ? extends String>)- 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.10 - [#6427] - This synthetic clause is no longer supported, useWindowPartitionByStep.partitionBy(Field...)
instead, or omit the clause entirely.- 3.10 - [#6427] - This synthetic clause is no longer supported, useWindowSpecificationPartitionByStep.partitionBy(Field...)
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.
-
ConstructorDescription- 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.
-
Enum 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.- [#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.- [#3844] - 3.6.0 -
SQLDialect.DEFAULT
will replace this pseudo-dialect.
Referencing
XYZ*Step
types directly from client codeIt is usually not recommended to reference any
XYZ*Step
types directly from client code, or assign them to local variables. When writing dynamic SQL, creating a statement's components dynamically, and passing them to the DSL API statically is usually a better choice. See the manual's section about dynamic SQL for details: https://www.jooq.org/doc/latest/manual/sql-building/dynamic-sql.Drawbacks of referencing the
XYZ*Step
types directly: