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.
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])
> 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. 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 :) )
>
> 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)
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)
Thank you,
Nikolay
--
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.
