Deprecated API
Contents
-
For Removal Element Description org.jooq.AlterDatabaseFinalStep - [#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
org.jooq.AlterDomainFinalStep - [#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
org.jooq.AlterIndexFinalStep - [#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
org.jooq.AlterSchemaFinalStep - [#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
org.jooq.AlterSequenceFinalStep - [#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
org.jooq.AlterTableFinalStep - [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directlyorg.jooq.AlterTypeFinalStep - [#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
org.jooq.AlterViewFinalStep - [#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
org.jooq.Clause - 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/7258org.jooq.CommentOnFinalStep - [#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
org.jooq.Comparator.supportsNulls() - 3.14.0 - [#9911] - This method is no longer supported.org.jooq.Comparator.supportsQuantifier() - 3.14.0 - [#9911] - This method is no longer supported.org.jooq.Comparator.supportsSubselect() - 3.14.0 - [#9911] - This method is no longer supported.org.jooq.ConditionProvider - 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.org.jooq.Configuration.schemaMapping() - 2.0.5 - UseConfiguration.settings()
insteadorg.jooq.ConstraintFinalStep - [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directlyorg.jooq.Context.formatIndentLockEnd() - [#10317] - 3.14.0 - Do not reuse this method. It will be removed without replacement.org.jooq.Context.formatIndentLockStart() - [#10317] - 3.14.0 - Do not reuse this method. It will be removed without replacement.org.jooq.Context.keyword(String) - 3.10.0 - [#4990] - UseDSL.keyword(String)
instead.org.jooq.Context.literal(String) - 3.10.0 - [#4990] - Use any ofDSL.name(String)
,DSL.quotedName(String)
orDSL.unquotedName(String)
instead.org.jooq.Converters.of() - [#10689] - 3.14.0 - This converter does not work. Do not use this method, useConverters.identity(Class)
instead.org.jooq.CreateDatabaseFinalStep - [#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
org.jooq.CreateDomainFinalStep - [#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
org.jooq.CreateIndexFinalStep - [#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
org.jooq.CreateSchemaFinalStep - [#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
org.jooq.CreateSequenceFinalStep - [#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
org.jooq.CreateTableFinalStep - [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directlyorg.jooq.CreateTypeFinalStep - [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directlyorg.jooq.CreateViewFinalStep - [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directlyorg.jooq.Cursor.fetch(int) - 3.10 - [#6363] - UseCursor.fetchNext(int)
instead.org.jooq.Cursor.fetchInto(H) - 3.15.0 - [#11902] - UseIterable.forEach(Consumer)
based methods, instead.org.jooq.Cursor.fetchNextInto(H) - 3.15.0 - [#11902] - UseIterable.forEach(Consumer)
based methods, instead.org.jooq.Cursor.fetchOne() - 3.10 - [#6363] - UseCursor.fetchNext()
instead.org.jooq.Cursor.fetchOneInto(H) - 3.10 - [#6363] - UseCursor.fetchNextInto(RecordHandler)
instead.org.jooq.Cursor.fetchOptional() - 3.10 - [#6363] - UseCursor.fetchNextOptional()
instead.org.jooq.Cursor.fetchOptionalInto(Class<? extends E>) - 3.10 - [#6363] - UseCursor.fetchNextOptionalInto(Class)
instead.org.jooq.DataType.defaulted(boolean) - [#3852] - 3.8.0 - UseDataType.defaultValue(Field)
instead.org.jooq.DeleteFinalStep - [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directlyorg.jooq.DropDatabaseFinalStep - [#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
org.jooq.DropDomainFinalStep - [#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
org.jooq.DropIndexFinalStep - [#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
org.jooq.DropSchemaFinalStep - [#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
org.jooq.DropSequenceFinalStep - [#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
org.jooq.DropTableFinalStep - [#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
org.jooq.DropTypeFinalStep - [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directlyorg.jooq.DropViewFinalStep - [#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
org.jooq.DSLContext.bindContext(PreparedStatement) - [#6280] - 3.10 - Do not reuse this method. It will be completely internal with jOOQ 4.0org.jooq.DSLContext.createOrReplaceView(String, Function<? super Field<?>, ? 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.org.jooq.DSLContext.createView(String, Function<? super Field<?>, ? 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.org.jooq.DSLContext.createViewIfNotExists(String, Function<? super Field<?>, ? 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.org.jooq.DSLContext.mergeInto(Table<R>, Field<T1>) - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.DSLContext.renderContext() - [#6280] - 3.10 - Do not reuse this method. It will be completely internal with jOOQ 4.0org.jooq.DSLContext.with(String, Function<? super Field<?>, ? 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.org.jooq.DSLContext.withRecursive(String, Function<? super Field<?>, ? 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.org.jooq.Field.abs() - 3.11 - [#7538] - UseDSL.abs(Field)
instead.org.jooq.Field.acos() - 3.11 - [#7538] - UseDSL.acos(Field)
instead.org.jooq.Field.as(Function<? super Field<T>, ? 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.org.jooq.Field.ascii() - 3.13 - [#9407] - UseDSL.ascii(Field)
instead.org.jooq.Field.asin() - 3.11 - [#7538] - UseDSL.asin(Field)
instead.org.jooq.Field.atan() - 3.11 - [#7538] - UseDSL.atan(Field)
instead.org.jooq.Field.atan2(Number) - 3.11 - [#7538] - UseDSL.atan2(Field, Number)
instead.org.jooq.Field.avg() - 3.11 - [#7538] - UseDSL.avg(Field)
instead.org.jooq.Field.avgOver() - 3.11 - [#7538] - UseDSL.avg(Field)
instead.org.jooq.Field.bitLength() - 3.13 - [#9407] - UseDSL.bitLength(Field)
instead.org.jooq.Field.ceil() - 3.11 - [#7538] - UseDSL.ceil(Field)
instead.org.jooq.Field.charLength() - 3.13 - [#9407] - UseDSL.charLength(Field)
instead.org.jooq.Field.coalesce(T, T...) - 3.13 - [#9407] - UseDSL.coalesce(Object, Object...)
instead.org.jooq.Field.cos() - 3.11 - [#7538] - UseDSL.cos(Field)
instead.org.jooq.Field.cosh() - 3.11 - [#7538] - UseDSL.cosh(Field)
instead.org.jooq.Field.cot() - 3.11 - [#7538] - UseDSL.cot(Field)
instead.org.jooq.Field.coth() - 3.11 - [#7538] - UseDSL.coth(Field)
instead.org.jooq.Field.count() - 3.11 - [#7538] - UseDSL.count(Field)
instead.org.jooq.Field.countDistinct() - 3.11 - [#7538] - UseDSL.countDistinct(Field)
instead.org.jooq.Field.countOver() - 3.11 - [#7538] - UseDSL.count(Field)
instead.org.jooq.Field.decode(T, Z) - 3.13 - [#9407] - UseDSL.decode(Object, Object, Object)
instead.org.jooq.Field.deg() - 3.11 - [#7538] - UseDSL.deg(Field)
instead.org.jooq.Field.exp() - 3.11 - [#7538] - UseDSL.exp(Field)
instead.org.jooq.Field.extract(DatePart) - 3.11 - [#7538] - UseDSL.extract(Field, DatePart)
instead.org.jooq.Field.firstValue() - 3.11 - [#7538] - UseDSL.firstValue(Field)
instead.org.jooq.Field.floor() - 3.11 - [#7538] - UseDSL.floor(Field)
instead.org.jooq.Field.greatest(T...) - 3.11 - [#7538] - UseDSL.greatest(Field, Field...)
instead.org.jooq.Field.lag() - 3.11 - [#7538] - UseDSL.lag(Field)
instead.org.jooq.Field.lastValue() - 3.11 - [#7538] - UseDSL.lastValue(Field)
instead.org.jooq.Field.lead() - 3.11 - [#7538] - UseDSL.lead(Field)
instead.org.jooq.Field.least(T...) - 3.11 - [#7538] - UseDSL.least(Field, Field...)
instead.org.jooq.Field.length() - 3.13 - [#9407] - UseDSL.length(Field)
instead.org.jooq.Field.ln() - 3.11 - [#7538] - UseDSL.ln(Field)
instead.org.jooq.Field.log(int) - 3.11 - [#7538] - UseDSL.log(Field, int)
instead.org.jooq.Field.lower() - 3.13 - [#9407] - UseDSL.lower(Field)
instead.org.jooq.Field.lpad(Field<? extends Number>) - 3.13 - [#9407] - UseDSL.lpad(Field, Field)
instead.org.jooq.Field.ltrim() - 3.13 - [#9407] - UseDSL.ltrim(Field)
instead.org.jooq.Field.max() - 3.11 - [#7538] - UseDSL.max(Field)
instead.org.jooq.Field.maxOver() - 3.11 - [#7538] - UseDSL.max(Field)
instead.org.jooq.Field.median() - 3.11 - [#7538] - UseDSL.median(Field)
instead.org.jooq.Field.min() - 3.11 - [#7538] - UseDSL.min(Field)
instead.org.jooq.Field.minOver() - 3.11 - [#7538] - UseDSL.min(Field)
instead.org.jooq.Field.nullif(T) - 3.13 - [#9407] - UseDSL.nullif(Field, Object)
instead.org.jooq.Field.nvl(T) - 3.13 - [#9407] - UseDSL.nvl(Field, Object)
instead.org.jooq.Field.nvl2(Z, Z) - 3.13 - [#9407] - UseDSL.nvl2(Field, Object, Object)
instead.org.jooq.Field.octetLength() - 3.13 - [#9407] - UseDSL.octetLength(Field)
instead.org.jooq.Field.position(String) - 3.13 - [#9407] - UseDSL.position(Field, String)
instead.org.jooq.Field.rad() - 3.11 - [#7538] - UseDSL.rad(Field)
instead.org.jooq.Field.repeat(Number) - 3.13 - [#9407] - UseDSL.repeat(Field, int)
instead.org.jooq.Field.replace(Field<String>) - 3.13 - [#9407] - UseDSL.replace(Field, Field)
instead.org.jooq.Field.round() - 3.11 - [#7538] - UseDSL.round(Field)
instead.org.jooq.Field.rpad(Field<? extends Number>) - 3.13 - [#9407] - UseDSL.rpad(Field, Field)
instead.org.jooq.Field.rtrim() - 3.13 - [#9407] - UseDSL.rtrim(Field)
instead.org.jooq.Field.sign() - 3.11 - [#7538] - UseDSL.sign(Field)
instead.org.jooq.Field.sin() - 3.11 - [#7538] - UseDSL.sin(Field)
instead.org.jooq.Field.sinh() - 3.11 - [#7538] - UseDSL.sinh(Field)
instead.org.jooq.Field.sqrt() - 3.11 - [#7538] - UseDSL.sqrt(Field)
instead.org.jooq.Field.stddevPop() - 3.11 - [#7538] - UseDSL.stddevPop(Field)
instead.org.jooq.Field.stddevPopOver() - 3.11 - [#7538] - UseDSL.stddevPop(Field)
instead.org.jooq.Field.stddevSamp() - 3.11 - [#7538] - UseDSL.stddevSamp(Field)
instead.org.jooq.Field.stddevSampOver() - 3.11 - [#7538] - UseDSL.stddevSamp(Field)
instead.org.jooq.Field.substring(int) - 3.13 - [#9407] - UseDSL.substring(Field, int)
instead.org.jooq.Field.sum() - 3.11 - [#7538] - UseDSL.sum(Field)
instead.org.jooq.Field.sumOver() - 3.11 - [#7538] - UseDSL.sum(Field)
instead.org.jooq.Field.tan() - 3.11 - [#7538] - UseDSL.tan(Field)
instead.org.jooq.Field.tanh() - 3.11 - [#7538] - UseDSL.tanh(Field)
instead.org.jooq.Field.trim() - 3.13 - [#9407] - UseDSL.trim(Field)
instead.org.jooq.Field.upper() - 3.13 - [#9407] - UseDSL.upper(Field)
instead.org.jooq.Field.varPop() - 3.11 - [#7538] - UseDSL.varPop(Field)
instead.org.jooq.Field.varPopOver() - 3.11 - [#7538] - UseDSL.varPop(Field)
instead.org.jooq.Field.varSamp() - 3.11 - [#7538] - UseDSL.varSamp(Field)
instead.org.jooq.Field.varSampOver() - 3.11 - [#7538] - UseDSL.varSamp(Field)
instead.org.jooq.FieldLike.asField(Function<? super Field<T>, ? 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.org.jooq.GrantFinalStep - [#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
org.jooq.impl.DefaultBinding(Converter<T, U>) - 3.11 - [#6631] - UseDefaultBinding.binding(Converter)
instead.org.jooq.impl.DefaultDSLContext.mergeInto(Table<R>, Field<T1>) - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDefaultDSLContext.mergeInto(Table)
org.jooq.impl.DSL.createOrReplaceView(String, Function<? super Field<?>, ? 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.org.jooq.impl.DSL.createView(String, Function<? super Field<?>, ? 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.org.jooq.impl.DSL.createViewIfNotExists(String, Function<? super Field<?>, ? 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.org.jooq.impl.DSL.getDataType(Class<T>) - 3.11.0 - [#7483] - The (indirect) use of the internal static data type registry is not recommended.org.jooq.impl.DSL.groupConcat(Field<?>, String) - [#7956] - 3.12.0 - UseDSL.groupConcat(Field)
andGroupConcatSeparatorStep.separator(String)
instead.org.jooq.impl.DSL.mergeInto(Table<R>, Field<T1>) - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSL.mergeInto(Table)
org.jooq.impl.DSL.nullSafe(Field<T>) - [#11092] - 3.15.0 - This method will be removed without public replacement.org.jooq.impl.DSL.nullSafeDataType(Field<T>) - [#11092] - 3.15.0 - This method will be removed without public replacement.org.jooq.impl.DSL.nullSafeList(Field<?>...) - [#11092] - 3.15.0 - This method will be removed without public replacement.org.jooq.impl.DSL.rowField(RowN) - [#11812] - 3.15.0 - UseRowN
as aSelectField
directly, instead.org.jooq.impl.DSL.sequence(String) - 3.10 - [#6162] - UseDSL.sequence(Name)
instead.org.jooq.impl.DSL.with(String, Function<? super Field<?>, ? 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.org.jooq.impl.DSL.withRecursive(String, Function<? super Field<?>, ? 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.org.jooq.impl.Internal.createForeignKey(UniqueKey<U>, Table<R>, String, TableField<R, ?>...) - 3.14.0 - [#9404] - Please re-generate your code.org.jooq.impl.Internal.createIndex(String, Table<?>, OrderField<?>[], boolean) - 3.14.0 - [#9404] - Please re-generate your code.org.jooq.impl.Internal.createUniqueKey(Table<R>, String, TableField<R, ?>...) - 3.14.0 - [#9404] - Please re-generate your code.org.jooq.impl.Internal.fields(TableField<R, ER>) - [#11058] - 3.14.5 - Please re-generate your code.org.jooq.impl.Internal.fieldsRow(TableField<R, ER>) - [#12238] - 3.16.0 - Please re-generate your code.org.jooq.impl.QOM.NotYetImplementedException - [#12425] - 3.16.0 - Missing implementations should be added as soon as possible!org.jooq.InsertFinalStep - [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directlyorg.jooq.LoaderCSVStep.fieldsFromSource() - 3.14.0 - [#10010] - UseLoaderCSVStep.fieldsCorresponding()
instead.org.jooq.LoaderJSONStep.fieldsFromSource() - 3.14.0 - [#10010] - UseLoaderJSONStep.fieldsCorresponding()
instead.org.jooq.LoaderListenerStep.onRow(LoaderRowListener) - 3.14.0 - [#4941] - UseLoaderListenerStep.onRowEnd(LoaderRowListener)
instead.org.jooq.LoaderRowsStep.fieldsFromSource() - 3.14.0 - [#10010] - UseLoaderRowsStep.fieldsCorresponding()
instead.org.jooq.MergeFinalStep - [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directlyorg.jooq.MergeKeyStep1 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeKeyStep1.key(Field<?>...) - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeKeyStep10 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeKeyStep10.key(Field<?>...) - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeKeyStep11 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeKeyStep11.key(Field<?>...) - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeKeyStep12 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeKeyStep12.key(Field<?>...) - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeKeyStep13 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeKeyStep13.key(Field<?>...) - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeKeyStep14 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeKeyStep14.key(Field<?>...) - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeKeyStep15 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeKeyStep15.key(Field<?>...) - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeKeyStep16 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeKeyStep16.key(Field<?>...) - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeKeyStep17 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeKeyStep17.key(Field<?>...) - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeKeyStep18 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeKeyStep18.key(Field<?>...) - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeKeyStep19 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeKeyStep19.key(Field<?>...) - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeKeyStep2 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeKeyStep2.key(Field<?>...) - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeKeyStep20 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeKeyStep20.key(Field<?>...) - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeKeyStep21 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeKeyStep21.key(Field<?>...) - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeKeyStep22 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeKeyStep22.key(Field<?>...) - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeKeyStep3 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeKeyStep3.key(Field<?>...) - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeKeyStep4 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeKeyStep4.key(Field<?>...) - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeKeyStep5 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeKeyStep5.key(Field<?>...) - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeKeyStep6 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeKeyStep6.key(Field<?>...) - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeKeyStep7 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeKeyStep7.key(Field<?>...) - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeKeyStep8 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeKeyStep8.key(Field<?>...) - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeKeyStep9 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeKeyStep9.key(Field<?>...) - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeUsingStep.columns(Field<?>...) - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep1 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep1.select(Select<? extends Record1<T1>>) - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep1.values(T1) - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep10 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep10.select(Select<? extends Record10<T1, T2, T3, T4, T5, T6, T7, T8, T9, T10>>) - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep10.values(T1, T2, T3, T4, T5, T6, T7, T8, T9, T10) - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep11 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep11.select(Select<? extends Record11<T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11>>) - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep11.values(T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11) - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep12 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep12.select(Select<? extends Record12<T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12>>) - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep12.values(T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12) - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep13 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep13.select(Select<? extends Record13<T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12, T13>>) - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep13.values(T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12, T13) - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep14 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep14.select(Select<? extends Record14<T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12, T13, T14>>) - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep14.values(T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12, T13, T14) - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep15 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep15.select(Select<? extends Record15<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)
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)
org.jooq.MergeValuesStep16 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep16.select(Select<? extends Record16<T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12, T13, T14, T15, T16>>) - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep16.values(T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12, T13, T14, T15, T16) - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep17 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep17.select(Select<? extends Record17<T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12, T13, T14, T15, T16, T17>>) - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep17.values(T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12, T13, T14, T15, T16, T17) - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep18 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep18.select(Select<? extends Record18<T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12, T13, T14, T15, T16, T17, T18>>) - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep18.values(T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12, T13, T14, T15, T16, T17, T18) - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep19 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep19.select(Select<? extends Record19<T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12, T13, T14, T15, T16, T17, T18, T19>>) - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep19.values(T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12, T13, T14, T15, T16, T17, T18, T19) - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep2 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep2.select(Select<? extends Record2<T1, T2>>) - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep2.values(T1, T2) - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep20 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep20.select(Select<? extends Record20<T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12, T13, T14, T15, T16, T17, T18, T19, T20>>) - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep20.values(T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12, T13, T14, T15, T16, T17, T18, T19, T20) - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep21 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep21.select(Select<? extends Record21<T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12, T13, T14, T15, T16, T17, T18, T19, T20, T21>>) - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep21.values(T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12, T13, T14, T15, T16, T17, T18, T19, T20, T21) - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep22 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep22.select(Select<? extends Record22<T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12, T13, T14, T15, T16, T17, T18, T19, T20, T21, T22>>) - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep22.values(T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12, T13, T14, T15, T16, T17, T18, T19, T20, T21, T22) - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep3 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep3.select(Select<? extends Record3<T1, T2, T3>>) - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep3.values(T1, T2, T3) - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep4 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep4.select(Select<? extends Record4<T1, T2, T3, T4>>) - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep4.values(T1, T2, T3, T4) - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep5 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep5.select(Select<? extends Record5<T1, T2, T3, T4, T5>>) - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep5.values(T1, T2, T3, T4, T5) - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep6 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep6.select(Select<? extends Record6<T1, T2, T3, T4, T5, T6>>) - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep6.values(T1, T2, T3, T4, T5, T6) - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep7 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep7.select(Select<? extends Record7<T1, T2, T3, T4, T5, T6, T7>>) - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep7.values(T1, T2, T3, T4, T5, T6, T7) - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep8 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep8.select(Select<? extends Record8<T1, T2, T3, T4, T5, T6, T7, T8>>) - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep8.values(T1, T2, T3, T4, T5, T6, T7, T8) - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep9 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep9.select(Select<? extends Record9<T1, T2, T3, T4, T5, T6, T7, T8, T9>>) - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep9.values(T1, T2, T3, T4, T5, T6, T7, T8, T9) - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.Name.fields(Function<? super Field<?>, ? 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.org.jooq.Param.setConverted(Object) org.jooq.Param.setInline(boolean) org.jooq.Param.setValue(T) org.jooq.Queries.stream() - 3.10 - [#6143] - UseQueries.queryStream()
instead.org.jooq.RecordHandler - 3.15.0 - [#11902] - UseIterable.forEach(Consumer)
based methods, instead.org.jooq.Result.intern(Field<?>...) - 3.10 - [#6254] - This functionality is no longer supported and will be removed in 4.0org.jooq.Result.into(H) - 3.15.0 - [#11902] - UseIterable.forEach(Consumer)
based methods, instead.org.jooq.ResultQuery.fetchInto(H) - 3.15.0 - [#11902] - UseIterable.forEach(Consumer)
based methods, instead.org.jooq.ResultQuery.intern(Field<?>...) - 3.10 - [#6254] - This functionality is no longer supported and will be removed in 4.0org.jooq.RevokeFinalStep - [#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
org.jooq.SchemaMapping - 2.0.5 - Use runtime configurationSettings
insteadorg.jooq.SelectQuery.setForUpdateNoWait() [#5218] - 3.14.0 - UseSelectQuery.setForLockModeNoWait()
org.jooq.SelectQuery.setForUpdateOf(Field<?>...) [#5218] - 3.14.0 - UseSelectQuery.setForLockModeOf(Field...)
org.jooq.SelectQuery.setForUpdateSkipLocked() [#5218] - 3.14.0 - UseSelectQuery.setForLockModeSkipLocked()
org.jooq.SelectQuery.setForUpdateWait(int) [#5218] - 3.14.0 - UseSelectQuery.setForLockModeWait(int)
org.jooq.SQLDialect.CUBRID - [#9403] - 3.13.0 - This dialect is hardly used by anyone with jOOQ or without jOOQ and will be removed in the near future.org.jooq.SQLDialect.IGNITE - [#12465] - 3.16.0 - This dialect is hardly used by anyone with jOOQ or without jOOQ and will be removed in the near future. If you're actively using this dialect, please get in touch for extended support: https://github.com/jOOQ/jOOQ/issues/12465org.jooq.SQLDialect.supports(Collection<SQLDialect>) - [#9882] - 3.14.0 - UseSQLDialect.supportedBy(SQLDialect...)
insteadorg.jooq.Table.as(String, Function<? super Field<?>, ? 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.org.jooq.TableLike.asTable(String, Function<? super Field<?>, ? 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.org.jooq.tools.Convert - 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)
.org.jooq.TruncateFinalStep - [#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
org.jooq.UpdateFinalStep - [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directlyorg.jooq.util.cubrid.CUBRIDDataType - 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.org.jooq.util.cubrid.CUBRIDDSL - 3.13.0 - [#9403] - This dialect is hardly used by anyone with jOOQ or without jOOQ and will be removed in the near future.org.jooq.util.derby.DerbyDataType - 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.org.jooq.util.derby.DerbyDSL - 3.15.0 - [#10796] - This class will be removed, soon, no more vendor specific DSL API will be added.org.jooq.util.firebird.FirebirdDataType - 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.org.jooq.util.firebird.FirebirdDSL - 3.15.0 - [#10796] - This class will be removed, soon, no more vendor specific DSL API will be added.org.jooq.util.h2.H2DataType - 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.org.jooq.util.h2.H2DSL - 3.15.0 - [#10796] - This class will be removed, soon, no more vendor specific DSL API will be added.org.jooq.util.hsqldb.HSQLDBDataType - 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.org.jooq.util.hsqldb.HSQLDBDSL - 3.15.0 - [#10796] - This class will be removed, soon, no more vendor specific DSL API will be added.org.jooq.util.ignite.IgniteDataType - 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.org.jooq.util.mariadb.MariaDBDataType - 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.org.jooq.util.mysql.MySQLDataType - 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.org.jooq.util.mysql.MySQLDSL.decode(String, String) - 3.15.0 - [#8611] - This function has been removed from MySQL 8org.jooq.util.mysql.MySQLDSL.desDecrypt(String) - 3.15.0 - [#8611] - This function has been removed from MySQL 8org.jooq.util.mysql.MySQLDSL.desEncrypt(String) - 3.15.0 - [#8611] - This function has been removed from MySQL 8org.jooq.util.mysql.MySQLDSL.encode(String, String) - 3.15.0 - [#8611] - This function has been removed from MySQL 8org.jooq.util.mysql.MySQLDSL.password(String) - 3.15.0 - [#8611] - This function has been removed from MySQL 8org.jooq.util.mysql.MySQLDSL.values(Field<T>) - 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/12099org.jooq.util.postgres.PostgresDataType - 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.org.jooq.util.postgres.PostgresDSL.oid(Table<?>) - [#12420] - 3.16.0 - Use actualOID
column references in jOOQ-meta, instead.org.jooq.util.sqlite.SQLiteDataType - 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.org.jooq.util.sqlite.SQLiteDSL - 3.15.0 - [#10796] - This class will be removed, soon, no more vendor specific DSL API will be added.org.jooq.util.yugabytedb.YugabyteDBDataType - 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.org.jooq.WindowFinalStep - [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directlyorg.jooq.WindowPartitionByStep.partitionByOne() - 3.10 - [#6427] - This synthetic clause is no longer supported, useWindowPartitionByStep.partitionBy(Field...)
instead, or omit the clause entirely.org.jooq.WindowSpecificationFinalStep - [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directlyorg.jooq.WindowSpecificationPartitionByStep.partitionByOne() - 3.10 - [#6427] - This synthetic clause is no longer supported, useWindowSpecificationPartitionByStep.partitionBy(Field...)
instead, or omit the clause entirely.org.jooq.WithStep.mergeInto(Table<R>, Field<T1>) - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaWithStep.mergeInto(Table)
org.jooq.WithStep.with(String, Function<? super Field<?>, ? 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.
-
Interfaces Interface Description org.jooq.AlterDatabaseFinalStep - [#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
org.jooq.AlterDomainFinalStep - [#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
org.jooq.AlterIndexFinalStep - [#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
org.jooq.AlterSchemaFinalStep - [#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
org.jooq.AlterSequenceFinalStep - [#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
org.jooq.AlterTableFinalStep - [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directlyorg.jooq.AlterTypeFinalStep - [#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
org.jooq.AlterViewFinalStep - [#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
org.jooq.CommentOnFinalStep - [#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
org.jooq.ConditionProvider - 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.org.jooq.ConstraintFinalStep - [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directlyorg.jooq.CreateDatabaseFinalStep - [#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
org.jooq.CreateDomainFinalStep - [#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
org.jooq.CreateIndexFinalStep - [#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
org.jooq.CreateSchemaFinalStep - [#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
org.jooq.CreateSequenceFinalStep - [#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
org.jooq.CreateTableFinalStep - [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directlyorg.jooq.CreateTypeFinalStep - [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directlyorg.jooq.CreateViewFinalStep - [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directlyorg.jooq.DeleteFinalStep - [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directlyorg.jooq.DropDatabaseFinalStep - [#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
org.jooq.DropDomainFinalStep - [#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
org.jooq.DropIndexFinalStep - [#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
org.jooq.DropSchemaFinalStep - [#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
org.jooq.DropSequenceFinalStep - [#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
org.jooq.DropTableFinalStep - [#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
org.jooq.DropTypeFinalStep - [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directlyorg.jooq.DropViewFinalStep - [#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
org.jooq.GrantFinalStep - [#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
org.jooq.InsertFinalStep - [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directlyorg.jooq.MergeFinalStep - [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directlyorg.jooq.MergeKeyStep1 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeKeyStep10 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeKeyStep11 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeKeyStep12 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeKeyStep13 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeKeyStep14 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeKeyStep15 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeKeyStep16 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeKeyStep17 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeKeyStep18 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeKeyStep19 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeKeyStep2 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeKeyStep20 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeKeyStep21 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeKeyStep22 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeKeyStep3 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeKeyStep4 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeKeyStep5 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeKeyStep6 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeKeyStep7 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeKeyStep8 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeKeyStep9 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep1 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep10 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep11 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep12 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep13 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep14 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep15 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep16 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep17 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep18 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep19 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep2 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep20 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep21 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep22 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep3 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep4 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep5 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep6 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep7 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep8 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.MergeValuesStep9 - [#10045] - 3.14.0 - Use the standard SQL MERGE API instead, viaDSLContext.mergeInto(Table)
org.jooq.RecordHandler - 3.15.0 - [#11902] - UseIterable.forEach(Consumer)
based methods, instead.org.jooq.RevokeFinalStep - [#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
org.jooq.TruncateFinalStep - [#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
org.jooq.UpdateFinalStep - [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directlyorg.jooq.WindowFinalStep - [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directlyorg.jooq.WindowSpecificationFinalStep - [#11329] - 3.15.0 - This type will be removed in the future. Do not reference it directly
-
Classes Class Description org.jooq.impl.AbstractKeys - [#6875] [#7158] - 3.11.0 - Please re-generate your codeorg.jooq.impl.DateToLocalDateConverter - 3.15.0 - [#11505] - UseConverter.ofNullable(Class, Class, Function, Function)
instead, e.g.Converter.ofNullable(Date.class, LocalDate.class, Date::toLocalDate, Date::valueOf)
.org.jooq.impl.TimestampToLocalDateTimeConverter - 3.15.0 - [#11505] - UseConverter.ofNullable(Class, Class, Function, Function)
instead, e.g.Converter.ofNullable(Timestamp.class, LocalDateTime.class, Timestamp::toLocalDateTime, Timestamp::valueOf)
.org.jooq.impl.TimeToLocalTimeConverter - 3.15.0 - [#11505] - UseConverter.ofNullable(Class, Class, Function, Function)
instead, e.g.Converter.ofNullable(Time.class, LocalTime.class, Time::toLocalTime, Time::valueOf)
.org.jooq.SchemaMapping - 2.0.5 - Use runtime configurationSettings
insteadorg.jooq.tools.Convert - 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)
.org.jooq.tools.jdbc.JDBC41Connection - 3.15.0 - [#11618] - This type is no longer used by jOOQ and will be removed in the future.org.jooq.tools.jdbc.JDBC41ResultSet - 3.15.0 - [#11618] - This type is no longer used by jOOQ and will be removed in the future.org.jooq.tools.jdbc.JDBC41Statement - 3.15.0 - [#11618] - This type is no longer used by jOOQ and will be removed in the future.org.jooq.util.cubrid.CUBRIDDataType - 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.org.jooq.util.cubrid.CUBRIDDSL - 3.13.0 - [#9403] - This dialect is hardly used by anyone with jOOQ or without jOOQ and will be removed in the near future.org.jooq.util.derby.DerbyDataType - 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.org.jooq.util.derby.DerbyDSL - 3.15.0 - [#10796] - This class will be removed, soon, no more vendor specific DSL API will be added.org.jooq.util.firebird.FirebirdDataType - 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.org.jooq.util.firebird.FirebirdDSL - 3.15.0 - [#10796] - This class will be removed, soon, no more vendor specific DSL API will be added.org.jooq.util.h2.H2DataType - 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.org.jooq.util.h2.H2DSL - 3.15.0 - [#10796] - This class will be removed, soon, no more vendor specific DSL API will be added.org.jooq.util.hsqldb.HSQLDBDataType - 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.org.jooq.util.hsqldb.HSQLDBDSL - 3.15.0 - [#10796] - This class will be removed, soon, no more vendor specific DSL API will be added.org.jooq.util.ignite.IgniteDataType - 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.org.jooq.util.jaxb.tools.TrimAdapter - 3.8.0 - [#4550] Do not reference this type directly.org.jooq.util.mariadb.MariaDBDataType - 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.org.jooq.util.mysql.MySQLDataType - 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.org.jooq.util.postgres.PostgresDataType - 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.org.jooq.util.sqlite.SQLiteDataType - 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.org.jooq.util.sqlite.SQLiteDSL - 3.15.0 - [#10796] - This class will be removed, soon, no more vendor specific DSL API will be added.org.jooq.util.yugabytedb.YugabyteDBDataType - 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.
-
Enums Enum Description org.jooq.Clause - 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/7258org.jooq.conf.RenderKeywordStyle org.jooq.conf.RenderNameStyle org.jooq.tools.JooqLogger.Level - UseLog.Level
instead
-
Exceptions Exceptions Description org.jooq.impl.QOM.NotYetImplementedException - [#12425] - 3.16.0 - Missing implementations should be added as soon as possible!
-
Constructors Constructor Description org.jooq.impl.CustomTable(String) - 3.10 - [#5996] - UseCustomTable(Name)
instead.org.jooq.impl.DefaultBinding(Converter<T, U>) - 3.11 - [#6631] - UseDefaultBinding.binding(Converter)
instead.org.jooq.impl.EmbeddableRecordImpl(Field<?>...) - [#11058] - 3.14.5 - Please re-generate your code.org.jooq.impl.SequenceImpl(String, Schema, DataType<T>) org.jooq.impl.TableImpl(String) - 3.10 - [#5996] - UseTableImpl(Name)
instead (or re-generated your code).
-
Enum Constants Enum Constant Description org.jooq.SQLDialect.CUBRID - [#9403] - 3.13.0 - This dialect is hardly used by anyone with jOOQ or without jOOQ and will be removed in the near future.org.jooq.SQLDialect.IGNITE - [#12465] - 3.16.0 - This dialect is hardly used by anyone with jOOQ or without jOOQ and will be removed in the near future. If you're actively using this dialect, please get in touch for extended support: https://github.com/jOOQ/jOOQ/issues/12465