Available in versions: Dev (3.20) | Latest (3.19) | 3.18 | 3.17 | 3.16 | 3.15 | 3.14 | 3.13 | 3.12 | 3.11 | 3.10
Declaration vs reference
Applies to ✅ Open Source Edition ✅ Express Edition ✅ Professional Edition ✅ Enterprise Edition
A few types of org.jooq.QueryPart
render different SQL depending on the context in which they are being rendered. The context is whether:
- The object is being declared
- The object is being referenced
A simple example is the aliasing of tables and columns. For example:
// Alias the table BOOK Book b = BOOK.as("B"); // Use the alias as a reference create.select(b.ID) // Use the alias as a declaration .from(b) .fetch();
In the above example, when referencing the table alias, jOOQ renders the alias only, i.e. B
. When declaring the table alias, jOOQ renders both the original table and its alias, i.e. BOOK as B
.
While it may appear useful to occasionally enter in a third rendering mode, which renders the original table BOOK
only, ignoring the alias, this isn't what is happening. If you want to access the original table (or column) reference, just keep a reference to that in your code, instead.
Types that expose this behaviour
The following types of org.jooq.QueryPart
expose this kind of context sensitive rendering behaviour:
-
org.jooq.Table
: Table expressions can be aliased tables which can be declared in the FROM clause, or similar clauses of other statements. -
org.jooq.Field
: Field expressions can be aliased columns which can be declared in the SELECT clause, or the RETURNING clauses of various statements. -
org.jooq.CommonTableExpression
: Common table expressions can be declared in the WITH clause of various statements. -
org.jooq.WindowDefinition
: Window definitions can be declared in the WINDOW clause of the SELECT statement. -
org.jooq.Parameter
: Routine parameters can be declared in the CREATE FUNCTION or CREATE PROCEDURE statements.
Feedback
Do you have any feedback about this page? We'd love to hear it!