3 ms·
> 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 `w
by continuational 11y ago
> 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.
- HCIdivision17 11y agoI'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.
- continuational 11y agoIf 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'
- lukaseder 11y agoYour 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).