Lukas, Thanks so much for your prompt and thorough response.
I agree with your position on Scala Options and SQL Nulls. This isn't a big deal since my Scala case classes simply don't have to use Option[String] for their types. The most important thing I care about is workflow and productivity. My dream is to be able to follow the following workflow: (1) Thoughtfully design my RDBMS and write out my DDL SQL for FlyWay to execute. (2) Apply it to Postgres (3) Run the jOOQ Code Generator (4) All my POJOs, most of my data access code, and the corresponding unit tests are now written I probably don't have the time but if I were to write the Scala generator, can you share any thoughts you have about the best approach? Based on a cursory code review, it looks like this would be as simple as writing a *ScalaGenerator.java* class that's modeled on the *JavaGenerator.java * at https://github.com/jOOQ/jOOQ/blob/master/jOOQ-codegen/src/main/java/org/jooq/util/JavaGenerator.java. Also, when I previously worked with jOOQ, I found that I would have liked to have had jOOQ auto-generate my unit tests for me as well (although in theory, why would you ever need auto-generated unit tests if the code itself is auto-generated). I wound up spending a lot of my time writing DAOs and their corresponding unit tests, and it would have been nice if I could have just auto-generated a stock DAO and then modified it from there. Do you see unit test generation as "in scope" for the code generator? As a native enhancement or a "custom extension"? Anyway, the good news is it sounds like full-blown Scala support in jOOQ isn't too far off (either in time or in amount of work to be done). While Slick is the most popular Scala library for ORM, I find the "idiomatic Scala to SQL" thought process quite awkward and opaque in some cases, even if it's intuitively easy to pick up. Josh On Tuesday, February 3, 2015 at 10:26:50 AM UTC-7, Lukas Eder wrote: > > 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] <javascript:>>: > >> >> >> 2015-02-03 16:48 GMT+01:00 Josh Padnick <[email protected] >> <javascript:>>: >> >>> 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.
