Hi Nikolay,
2013/6/11 <[email protected]> > Hello! > > We are trying jOOQ as dynamic query builder, in addition to static Slick's > queries > 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. > And while evaluating it, the next question arised: > we are using for nullable columns datatype representation as > Option[columnType], so we always know when we are use smth nullable and > when not. > So, how can we do it with jOOQ? Maybe, custom type mappers or smth? > 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>>. 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. Note that jOOQ also supports code generation for JSR-303 bean validation annotations, which is another way to communicate nullability / non-nullability. I'm curious what other users on this group think about integrating "Option" Cheers Lukas [1]: http://blog.jooq.org/2013/02/14/jooqs-reason-of-being [2]: http://blog.jooq.org/2013/04/11/on-java-8s-introduction-of-optional -- 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.
