4 ms·
>Strongly typed lanaguages are even cooler here ... No expereince with Slick in particular; but I've been using jOOq[1] which I believe is similar. To be hone
by drbawb 12y ago
>Strongly typed lanaguages are even cooler here ...
No expereince with Slick in particular; but I've been using jOOq[1] which I believe is similar.
To be honest I'm not entirely sold that these DSLs are what I'd consider "strongly typed." I can get jOOq to pretty easily yield queries that won't work if I switch out database dialects. (Ignoring, for a moment, that jOOq will let you embed SQL fragments as strings.)
As an example: jOOq will happily let you write an update query targeting a table bound to an alias. This type checks just fine. In fact this query will even work in Postgres; but it yields a syntax error from the database if you target SQL Server 2008 instead.
Then there's the issue of the dialects letting you use features the RDBMS doesn't support. For example you can build a merge statement regardless of which dialect is selected. If you were to select the Postgres dialect you'll get an "unsupported exception" at runtime.
If a method is RDBMS specific (in practice) then why is it part of the generic API?
---
My biggest beef with all these SQL abstraction layers is that many of them claim to be "write once, run anywhere." In practice I've just never seen that to be true.
I wish they would incorporate some sort of "capabilities" system that could run at compile time. Just imagine: when you swap in the Postgres driver your IDE throws a little red squiggle under the `.merge()` call, "method not found."
[1]: http://www.jooq.org/ http://www.jooq.org/
- lukaseder 12y ago> To be honest I'm not entirely sold that these DSLs are what I'd consider "strongly typed." Absolutely! They're "quite" typesafe, much more than string-based SQL. Much less than actual compiled stored procedures. > As an example: jOOq will happily let you write an update query targeting a table bound to an alias. Yes, that currently cannot be detected. > Then there's the issue of the dialects letting you use features the RDBMS doesn't support That will be addressed in the near future when we implement an API "preprocessor" that will effectively remove all parts of the API that are not supported by your given dialect. We'll also distinguish between native support and emulated support, if this strictness matters in your application. The relevant issue is here: https://github.com/jOOQ/jOOQ/issues/720 https://github.com/jOOQ/jOOQ/issues/720 > In practice I've just never seen that to be true. True, but if you need "write once, run anywhere", you're probably much better off with a headstart than if you started from scratch.
- twic 12y ago> To be honest I'm not entirely sold that these DSLs are what I'd consider "strongly typed." I can get jOOq to pretty easily yield queries that won't work if I switch out database dialects. I can get Hibernate to pretty easily yield queries that won't work if I use a mildly unusual combination of JPA features. weeps
- lukaseder 12y ago> I can get jOOq to pretty easily yield queries that won't work if I switch out database dialects. In fact, you can do this with SQL. The following is perfectly valid in MySQL but not in any of the other dialects: SELECT a, b, COUNT(*) FROM t GROUP BY a SQL is so heavy with implicit semantics that cannot be expressed in syntax alone...