2013/7/14 Christopher Deckers <[email protected]>
> Hi Lukas,
>
> What I'm trying to say is, it may be worth evaluating to write scooq,
>> instead of adding 1-2 utilities to jOOQ. Or since Scala is mainly
>> functional, not OO, a "better" name might be scfq ;-)
>>
>
> Remember that Java 8 is coming and you may have to think of "jFQ" too :)
>
I've had a couple of chats about this topic with Thomas Müller, the
maintainer of the H2 database and of JaQu [1]. He's really interested in
that topic, thinking about adding functional-style predicates to his fluent
SQL API. JaQu is already "more embedded" in Java than jOOQ, as it plays a
lot with constructors, byte-code instrumentation (i.e. decompiling byte
code to generate SQL) and the "double-curly-braces" technique.
I'm personally not a fan of these features at all. While they're fun to
play around with, and fun to talk about with Thomas Müller, I really think
that LINQ-style APIs will bring the next big impedance mismatch to us
developers: The idea of being able to merge programming paradigms (OO,
functional, declarative). In my opinion, specifically, SQL's declarative
style should not be mixed with anything else, if you want predictable SQL.
It's perfectly OK, though, to apply functional mappers onto jOOQ Result
objects, once they have been obtained from the database. Something like
this is already possible today:
DSL.using(configuration)
.select(...)
.from(...)
.fetch((Record r) -> transform(r));
Replace "(...) -> transform(r)" with your own lambda.
Cheers
Lukas
[1]: http://www.h2database.com/html/jaqu.html
--
You received this message because you are subscribed to the Google Groups "jOOQ
User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
