equals

Check whether this QueryPart can be considered equal to
another QueryPart.

In general, QueryPart equality is defined in terms of
QueryPart.toString() equality. In other words, two query parts are
considered equal if their rendered SQL (with inlined bind variables) is
equal. This means that the two query parts do not necessarily have to be
of the same type.

Some QueryPart implementations may choose to override this
behaviour for improved performance, as QueryPart.toString() is an
expensive operation, if called many times.

coerce

Unlike with casting, coercing doesn't affect the way the database sees a
Field's type. This is how coercing affects your SQL:

Bind values

// This binds an int value to a JDBC PreparedStatement
DSL.val(1).coerce(String.class);
// This binds an int value to a JDBC PreparedStatement
// and casts it to VARCHAR in SQL
DSL.val(1).cast(String.class);

Other Field types

// This fetches a String value for the BOOK.ID field from JDBC
BOOK.ID.coerce(String.class);
// This fetches a String value for the BOOK.ID field from JDBC
// after casting it to VARCHAR in the database
BOOK.ID.cast(String.class);

coerce

Unlike with casting, coercing doesn't affect the way the database sees a
Field's type. This is how coercing affects your SQL:

Bind values

// This binds an int value to a JDBC PreparedStatement
DSL.val(1).coerce(String.class);
// This binds an int value to a JDBC PreparedStatement
// and casts it to VARCHAR in SQL
DSL.val(1).cast(String.class);

Other Field types

// This fetches a String value for the BOOK.ID field from JDBC
BOOK.ID.coerce(String.class);
// This fetches a String value for the BOOK.ID field from JDBC
// after casting it to VARCHAR in the database
BOOK.ID.cast(String.class);

coerce

Unlike with casting, coercing doesn't affect the way the database sees a
Field's type. This is how coercing affects your SQL:

Bind values

// This binds an int value to a JDBC PreparedStatement
DSL.val(1).coerce(String.class);
// This binds an int value to a JDBC PreparedStatement
// and casts it to VARCHAR in SQL
DSL.val(1).cast(String.class);

Other Field types

// This fetches a String value for the BOOK.ID field from JDBC
BOOK.ID.coerce(String.class);
// This fetches a String value for the BOOK.ID field from JDBC
// after casting it to VARCHAR in the database
BOOK.ID.cast(String.class);

If this is not supported by the underlying database, jOOQ will render
this instead:

CASE WHEN [this] IS NULL AND [value] IS NULL THEN FALSE
WHEN [this] IS NULL AND [value] IS NOT NULL THEN TRUE
WHEN [this] IS NOT NULL AND [value] IS NULL THEN TRUE
WHEN [this] = [value] THEN FALSE
ELSE TRUE
END

If this is not supported by the underlying database, jOOQ will render
this instead:

CASE WHEN [this] IS NULL AND [field] IS NULL THEN FALSE
WHEN [this] IS NULL AND [field] IS NOT NULL THEN TRUE
WHEN [this] IS NOT NULL AND [field] IS NULL THEN TRUE
WHEN [this] = [field] THEN FALSE
ELSE TRUE
END

If this is not supported by the underlying database, jOOQ will render
this instead:

CASE WHEN [this] IS NULL AND [value] IS NULL THEN TRUE
WHEN [this] IS NULL AND [value] IS NOT NULL THEN FALSE
WHEN [this] IS NOT NULL AND [value] IS NULL THEN FALSE
WHEN [this] = [value] THEN TRUE
ELSE FALSE
END

If this is not supported by the underlying database, jOOQ will render
this instead:

CASE WHEN [this] IS NULL AND [field] IS NULL THEN TRUE
WHEN [this] IS NULL AND [field] IS NOT NULL THEN FALSE
WHEN [this] IS NOT NULL AND [field] IS NULL THEN FALSE
WHEN [this] = [value] THEN TRUE
ELSE FALSE
END

This translates to
this ilike ('%' || escape(value, '\') || '%') escape '\' in
SQLDialect.POSTGRES, or to
lower(this) not like lower(('%' || escape(value, '\') || '%') escape '\')
in all other dialects.

in

Note that generating dynamic SQL with arbitrary-length IN
predicates can cause cursor cache contention in some databases that use
unique SQL strings as a statement identifier (e.g.
SQLDialect.ORACLE). In order to prevent such problems, you could
use Settings.isInListPadding() to produce less distinct SQL
strings (see also
[#5600]), or you
could avoid IN lists, and replace them with:

IN predicates on temporary tables

IN predicates on unnested array bind variables

in

Create a condition to check this field against several values from a
previous query.

SQL: this in (values...)

Note that generating dynamic SQL with arbitrary-length IN
predicates can cause cursor cache contention in some databases that use
unique SQL strings as a statement identifier (e.g.
SQLDialect.ORACLE). In order to prevent such problems, you could
use Settings.isInListPadding() to produce less distinct SQL
strings (see also
[#5600]), or you
could avoid IN lists, and replace them with:

IN predicates on temporary tables

IN predicates on unnested array bind variables

in

Note that generating dynamic SQL with arbitrary-length IN
predicates can cause cursor cache contention in some databases that use
unique SQL strings as a statement identifier (e.g.
SQLDialect.ORACLE). In order to prevent such problems, you could
use Settings.isInListPadding() to produce less distinct SQL
strings (see also
[#5600]), or you
could avoid IN lists, and replace them with:

notIn

Note that if any of the passed values is NULL, then the
condition will be NULL (or false, depending on
the dialect) as well. This is standard SQL behaviour.

SQL: this not in (values...)

Note that generating dynamic SQL with arbitrary-length
NOT IN predicates can cause cursor cache contention in some
databases that use unique SQL strings as a statement identifier (e.g.
SQLDialect.ORACLE). In order to prevent such problems, you could
use Settings.isInListPadding() to produce less distinct SQL
strings (see also
[#5600]), or you
could avoid IN lists, and replace them with:

notIn

Create a condition to check this field against several values from a
previous query.

Note that if any of the passed values is NULL, then the
condition will be NULL (or false, depending on
the dialect) as well. This is standard SQL behaviour.

SQL: this in (values...)

Note that generating dynamic SQL with arbitrary-length
NOT IN predicates can cause cursor cache contention in some
databases that use unique SQL strings as a statement identifier (e.g.
SQLDialect.ORACLE). In order to prevent such problems, you could
use Settings.isInListPadding() to produce less distinct SQL
strings (see also
[#5600]), or you
could avoid IN lists, and replace them with:

notIn

Note that if any of the passed values is NULL, then the
condition will be NULL (or false, depending on
the dialect) as well. This is standard SQL behaviour.

SQL: this not in (values...)

Note that generating dynamic SQL with arbitrary-length
NOT IN predicates can cause cursor cache contention in some
databases that use unique SQL strings as a statement identifier (e.g.
SQLDialect.ORACLE). In order to prevent such problems, you could
use Settings.isInListPadding() to produce less distinct SQL
strings (see also
[#5600]), or you
could avoid IN lists, and replace them with: