There are a tremendous amount of SQL APIs natively written in Scala.
Manuel Bernhardt has summarised a nice collection in his a post. Another collection of
Scala SQL APIs can be seen in this Stack Overflow question.
One API that we want to focus on in particular is
ScalikeJDBC (
licensed ASL 2.0), which has recently published a SQL query DSL API similar to that of
jOOQ. See the full documentation here:
http://scalikejdbc.org/documentation/query-dsl.html
A couple of examples:
val orders: List[Order] = withSQL {
select
.from(Order as o)
.innerJoin(Product as p).on(o.productId, p.id)
.leftJoin(Account as a).on(o.accountId, a.id)
.where.eq(o.productId, 123)
.orderBy(o.id).desc
.limit(4)
.offset(0)
}.map(Order(o, p, a)).list.apply()
The above example looks very similar to
jOOQ code, except that the
SELECT
DSL seems to be a bit more rigid than jOOQ’s. For instance, it is not immediately obvious how to connect several complex predicates in that
WHERE
clause, or if complex predicates are available at all.
What’s really nice, however, is their way of leveraging Scala language features to provide a very fluent way of constructing dynamic SQL, as can be seen in this example:
def findOrder(id: Long, accountRequired: Boolean) =
withSQL {
select
.from[Order](Order as o)
.innerJoin(Product as p).on(o.productId, p.id)
.map { sql =>
if (accountRequired)
sql.leftJoin(Account as a)
.on(o.accountId, a.id)
else
sql
}.where.eq(o.id, 13)
}.map { rs =>
if (accountRequired)
Order(o, p, a)(rs)
else
Order(o, p)(rs)
}.single.apply()
From how we understand things, the
map
method that is invoked in the middle of the SQL statement (between
innerJoin
and
where
) can transform the intermediate DSL state using a lambda expression that allows for appending a
leftJoin
if needed. Obviously, this can be done in a more procedural fashion as well, by assigning that intermediate DSL state to a local variable.
The need for SQL query DSLs
We’ve blogged about many of these similar SQL query DSLs in the past. The fact that they constantly pop up in various APIs is no coincidence. SQL is a very typesafe and composable language that is hard to use dynamically through string-based APIs such as JDBC, ODBC, etc.
Having a typesafe internal domain-specific language model SQL in a host language like Java or Scala brings great advantages. But the disadvantages may shine through quickly, when the DSL is not carefully crafted in a completely foreseeable way. Take the following ScalikeJDBC QueryDSL example, for instance:
val ids = withSQL {
select(o.result.id).from(Order as o)
.where(sqls.toAndConditionOpt(
productId.map(id => sqls.eq(o.productId, id)),
accountId.map(id => sqls.eq(o.accountId, id))
))
.orderBy(o.id)
}.map(_.int(1)).list.apply()
This
toAndConditionOpt
method is really unexpected and doesn’t follow the
principle of least astonishment.
This is why jOOQ’s API design is based on a formal BNF that closely mimicks SQL itself.
Read more about that here.
Like this:
Like Loading...
Published by lukaseder
I made jOOQ
View all posts by lukaseder