Hi Nicolay, 2013/6/11 <[email protected]> > Thank you for fast response! > > > >> Now that's an interesting approach. How does that work out for you? The >> two APIs have very different goals [1]. It's interesting for me to learn >> about the motivation of such an integration. >> > > Slick works nicely for simple static (defined on compile-time) queries, > but no one answered the question [1] about dynamic query building we need > for organizing UI. >
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 > As far as I know slick is bounded to TupleN representation on query result > (there is one trick how to overcome limitation of 22 tuple members until > scala 2.11, but it doesn't matter to my problem). So I don't understand (I > supposed it's impossible) how to change query result time in runtime (based > on user input, see my explanations in [1]) > 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. > I have to admit that I have not yet thought about that. Scala is "ahead" >> of Java with respect to finding a long-term solution to the nullability >> problem [2]. Just to get this right. What you plan on doing is to bind >> things like Option<Integer> (or Option[Int]) to T in jOOQ's Field<T> type? >> E.g. to have the code generator render things like >> org.jooq.Field<Option<Integer>**>. >> > > exactly so. > > >> > As jOOQ's converter mechanism relies on unambiguously identifiable T >> types, I guess you will have to explicitly subtype Option<T> first, as in >> >> - IntegerOption extends Option<Integer> >> - StringOption extends Option<String> >> - etc. >> >> Then, it might be possible to achieve what you want using jOOQ's >> converter feature. >> > > Ok, we will play a bit with meta model... I'll keep posting. Thank you for > pointing. > Looking forward to hearing your findings! > One more interesting thing: > if we have TableA(id number not null, idTableB number) and TableB(id > number not null) and FK TableA.idTableB -> TableA.id then > select idTableB from TableA should be Option[TypeOfID] > but select idTableB from TableA A inner join TableB B on (A.idTableB = > B.id) should be TypeOfID > and select idTableB from TableA A left join TableB B on (A.idTableB = > B.id) should be Option[TypeOfID] again > > of course, that's an ideal world, but can be implemented in scala (really > don't know about java :) ) > 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! > Note that jOOQ also supports code generation for JSR-303 bean validation >> annotations, which is another way to communicate nullability / >> non-nullability. >> > > Oh, that's possible, of course, but we prefer scala's way) > Fair enough > One more question: if I want to use query templates like > val a = ORG_JUR as("A") > val b = CMN_JURCONTRACTOR as("B") > val qry = dsl select(a.SCAPTION, a.DIJURCONTRACTOR) from(a) where > a.DI === (new java.math.BigDecimal(1.1)) > val qryNext = dsl select(b.DICONTRACTOR) from(b) > > what's the best way to define these templates (qry, qryNext) for further > using column aliases like here? Is it possible in some way? (with declaring > special class for it) > val result = > dsl.select(qty.SCAPTION).from(qry).join(qryNext).on(qry. DIJURCONTRACTOR > === qryNext. DICONTRACTOR) > 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. Cheers Lukas -- 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.
