Hello!
> I think I have previously observed this strong focus towards "inline
> querying" in slick. It goes well with Scala's (and functional
> programming's) general idea of making as many things immutable as possible.
>
> jOOQ is more "mutable", which helps creating dynamic SQL. In jOOQ 4.0, I
> plan to cleanly separate mutable (dynamic SQL) and immutable (inline SQL)
> aspects of the jOOQ API:
> https://github.com/jOOQ/jOOQ/issues/2198
>
>
Well, immutability is not a problem for dynamic SQL. It's all about
expected level of typesafety.
>
>> Yes, I had been following those threads. jOOQ uses Row1, Row2, ...,
> Row22, RowN types, or Record1, Record2, ..., Record22, Record, where the
> last type models degrees > 22. While the generic typesafety is lost, it is
> still possible to continue operating in scenarios, which aren't so unlikely
> in SQL. I wonder if Scala will be able to find a non-workaroundy solution
> to this issue.
>
>
Two things may come to the rescue: HLists or restricted functionality of
case classes for arity > 22 (but rich enough for slick). I'd prefer HLists
:) because it's very useful thing but quit complex to work with. But I
think in 2.11 will be the second variant.
>
>>> Looking forward to hearing your findings!
>
>
well, here [1] is the first take. Please take a look on it... I don't like
ActiveRecord pattern so I suppose table definitions (tableRec definitions)
maybe even more if I don't need this functionality. Currently I just
translated piece of your generated code in scala way and added generic
Option converter
> I don't think that Java's (and thus, jOOQ's) type system is powerful
> enough to model such typesafety in an API. It would certainly be great,
> though!
>
yes, I know it's possible it clean scala lib, not sure if it's possible on
scala wrapper for java lib (roots are deep) and I think it's not possible
in clean java.)
>
> Unfortunately, this isn't possible as elegantly as you'd like to do that.
> What you can do is this:$
>
> val qry2 = qry.asTable("qry");
> val SCAPTION = qry2.field(OMG_JUR.SCAPTION);
>
> and then
>
> dsl.select(SCAPTION).from(qry2).join(...)
>
> You get the idea. I would be very happy to introduce more typesafety in
> the area of derived tables, but I'm afraid I currently don't see how this
> could be done, easily.
>
I'll play a bit here too...
[1]: https://gist.github.com/newffy/5771895
--
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.
