I've just tried the Options again, and in fact the following converter will
work:
class StringOptionConverter extends Converter[String, Option[String]] {
override def from(t : String) : Option[String] =
if (t == null)
None
else
Some(t)
override def to(u : Option[String]) : String =
u match {
case None => null
case Some(s) => s
}
override def fromType : Class[String] = classOf[String]
override def toType : Class[Option[String]] = classOf[Option[String]]
}
It can be configured like this:
<customTypes>
<customType>
<name>Option[String]</name>
<type>scala.Option<String></type>
<converter>org.jooq.scala.StringOptionConverter</converter>
</customType>
</customTypes>
<forcedTypes>
<forcedType>
<name>Option[String]</name>
<expression>.*\.first_name</expression>
</forcedType>
</forcedTypes>
This will work, but in my opinion, Option is the wrong tool to model SQL's
NULL (or any language's NULL) as it abuses generics for the job. In SQL,
and in most languages, it is OK to compare something that is semantically
nullable with something that is not. In Java/Scala using generics,
Option[T] cannot be compared with T, e.g. by writing
NULLABLE_FIELD.eq(NON_NULLABLE_FIELD).
In other words, using generics to model a second-class piece of information
such as SQL's NULL / NOT NULL is probably not good.
As far as Int is concerned...
While you could write an IntConverter like this:
class IntConverter extends Converter[java.lang.Integer, Int] {
override def from(t : java.lang.Integer) : Int = t.intValue()
override def to(u : Int) : java.lang.Integer = java.lang.Integer.valueOf(u)
override def fromType : Class[java.lang.Integer] = classOf[java.lang.Integer]
override def toType : Class[Int] = classOf[Int]
}
You might not be able to use it in the code generator, because the
generated code is Java code, and the Converter[Integer, Int] type is
translated to Converter<Integer, Object>. In order to be able to use Int
and the other "primitive" types from Scala, you'd have to rewrite the code
generator to produce actual scala code (
https://github.com/jOOQ/jOOQ/issues/4021).
Long story short, this part of the interoperability might not yet be as
lean as if jOOQ were written in Scala.
2015-02-03 17:00 GMT+01:00 Lukas Eder <[email protected]>:
>
>
> 2015-02-03 16:48 GMT+01:00 Josh Padnick <[email protected]>:
>
>> Hello there. I'm chiming in on this thread 10 months later.
>>
>> I'm about to begin a new project with Play Framework and Scala and would
>> like to use jOOQ over Slick if I can. Have there been any significant
>> updates in either documentation or Scala integration that Scala users might
>> find helpful since this was originally posted in March 20, 2014?
>>
>
> No, it hasn't been a priority in 2014
>
>
>> Any success stories of Scala users going to production with jOOQ?
>>
>
> We have a couple of paying customers who have gone live with jOOQ and we
> haven't heard from them apart from subscription renewal, so I take that as
> a good sign.
>
>
>> I prefer the jOOQ paradigm but am nervous about edge cases I may run into
>> down the line.
>>
>
> The only edge cases that I'm aware of are lack of support for scala.Option
> and a lack of support for scala.Int et al., although one of the more
> interesting driving forces behind jOOQ 3.5's org.jooq.Binding API is to
> enable support for these user types.
>
> *Hopefully, other users might see this discussion and chime in, too*
>
--
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/d/optout.
