jOOQ takes SQL as an external domain-specific language and maps it onto Java, creating an internal domain-specific language. Internal DSLs cannot 100% implement their external language counter parts, as they have to adhere to the syntax rules of their host or target language (i.e. Java). This section explains the various problems and workarounds encountered and implemented in jOOQ.
@@ -10526,19 +10526,19 @@ SERVER = new RemoteDebuggerServer(DEBUGGER_PORT);
SQL syntax does not always need keywords to form expressions. The
The above example also shows missing operator overloading capabilities, where "=" is replaced by "," in jOOQ. Another example are , which can be formed with parentheses only in SQL:
-
+
(a, b) IN ((1, 2), (3, 4))
row(a, b).in(row(1, 2), row(3, 4))
-
+
In this case, ROW is an actual (optional) SQL keyword, implemented by at least PostgreSQL.
@@ -10549,27 +10549,27 @@ SERVER = new RemoteDebuggerServer(DEBUGGER_PORT);
As most languages, SQL does not attribute any meaning to whitespace. However, whitespace is important when forming "composed" keywords, i.e. SQL clauses composed of several keywords. jOOQ follows standard Java method naming conventions to map SQL keywords (case-insensitive) to Java methods (case-sensitive, camel-cased). Some examples:
-
+
GROUP BY
ORDER BY
WHEN MATCHED THEN UPDATE
groupBy()
orderBy()
whenMatchedThenUpdate()
-
+
Future versions of jOOQ may use all-uppercased method names in addition to the camel-cased ones (to prevent collisions with Java keywords):
-
+
GROUP BY
ORDER BY
WHEN MATCHED THEN UPDATE
GROUP_BY()
ORDER_BY()
WHEN_MATCHED_THEN_UPDATE()
-
+
SQL contains "superfluous" keywords
@@ -10584,10 +10584,10 @@ WHEN_MATCHED_THEN_UPDATE()
jOOQ omits some of those keywords when it is too tedious to write them in Java.
-
+
CASE WHEN .. THEN .. END
decode().when(.., ..)
-
+
The above example omits THEN and END keywords in Java. Future versions of jOOQ may comprise a more complete DSL, including such keywords again though, to provide a more 1:1 match for the SQL language.
@@ -10598,23 +10598,23 @@ WHEN_MATCHED_THEN_UPDATE()
Some SQL constructs are hard to map to Java, but they are also not really necessary. SQL often expects syntactic parentheses where they wouldn't really be needed, or where they feel slightly inconsistent with the rest of the SQL language.
-
+
LISTAGG(a, b) WITHIN GROUP (ORDER BY c)
OVER (PARTITION BY d)
listagg(a, b).withinGroupOrderBy(c)
.over().partitionBy(d)
-
+
The parentheses used for the WITHIN GROUP (..) and OVER (..) clauses are required in SQL but do not seem to add any immediate value. In some cases, jOOQ omits them, although the above might be optionally re-phrased in the future to form a more SQLesque experience:
-
+
LISTAGG(a, b) WITHIN GROUP (ORDER BY c)
OVER (PARTITION BY d)
listagg(a, b).withinGroup(orderBy(c))
.over(partitionBy(d))
-
+
SQL uses some of Java's reserved words
@@ -10630,12 +10630,12 @@ WHEN_MATCHED_THEN_UPDATE()
jOOQ replaces those keywords by "synonyms":
-
+
CASE .. ELSE
PIVOT .. FOR .. IN ..
decode() .. otherwise()
pivot(..).on(..).in(..)
-
+
There is more future collision potential with:
@@ -10658,7 +10658,7 @@ pivot(..).on(..).in(..)
Most SQL operators have to be mapped to descriptive method names in Java, as Java does not allow operator overloading:
-
+
, !=
||
@@ -10667,61 +10667,61 @@ SET a = b]]>
notEqual(), ne()
concat()
set(a, b)
-
+
For those users using , operator overloading and implicit conversion can be leveraged to enhance jOOQ:
-
+
, !=
||]]>
, !==
||]]>
-
+
SQL's reference before declaration capability
This is less of a syntactic SQL feature than a semantic one. In SQL, objects can be referenced before (i.e. "lexicographically before") they are declared. This is particularly true for
-
+
-
+
A more sophisticated example are common table expressions (CTE), which are currently not supported by jOOQ:
-WITH t(a, b) AS (
+WITH t(a, b) AS (
SELECT 1, 2 FROM DUAL
)
SELECT t.a, t.b
-FROM t
+FROM t
Common table expressions define a "derived column list", just like can do. The formal record type thus created cannot be typesafely verified by the Java compiler, i.e. it is not possible to formally dereference t.a from t.
-
+