Hacker News Reader

Comment by continuational | Hacker News Reader

> type safe SQL queries

Really? So the compiler will catch this error?

    create.select().from(AUTHOR).where(BOOK.LANGUAGE.eq("DE"))

No it won't, because `where` has this type:

    SelectConditionStep<R> where(Field<Boolean> field)

If it was type safe, `Field<Boolean>` would have to mention the type of the records that can be queried.

Type safety is what is being sold on the front page as the main value proposition.

Needless to say, I'm not sold on it.

View on HN

Your criticism is certainly valid. The SQL language can be type checked using Java types only to a certain degree. There is no way to type check SQL thoroughly without an actual parser, though. For example, your query would be fine again (although a bit pointless) as a subquery:

    create.select()
          .from(BOOK)
          .where(exists(
              create.select().from(AUTHOR).where(BOOK.LANGUAGE.eq("DE"))
          ))

Other frameworks may have jumped to the conclusion that predicates should be strictly tied to whatever is placed in the FROM clause. This is possible only if you completely limit the scope of what your framework can do (namely CRUD).

I'm not sure I understand; doesn't

  BOOK.LANGUAGE.eq("DE")

mean something like

  Book.Language = 'DE'

in SQL? That's certainly a boolean expression. I've only started reading the manual, though, so it's possible I got the semantics wrong, but I've had SSMS point out to me this sort of thing before.

If we had selected from or joined on BOOK, it would be a Boolean expression. But in this case, BOOK is undefined, so BOOK.LANGUAGE.eq("DE") shouldn't type check at all.

The corresponding SQL is nonsensical:

    select * from AUTHOR where BOOK.LANGUAGE = 'DE'

Reply on news.ycombinator.com