Hi Josh, 2015-02-04 16:03 GMT+01:00 Josh Padnick <[email protected]>:
> 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 > OK, so that already works, then :) Just in case you or other readers weren't aware of this blog post and manual section: - http://blog.jooq.org/2014/06/25/flyway-and-jooq-for-unbeatable-sql-development-productivity/ - http://www.jooq.org/doc/3.5/manual/getting-started/tutorials/jooq-with-flyway/ > 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 > . > Yes, the JavaGenerator is pretty much all there is to it. It can be configured from the code generation configuration. Of course you could also write one completely from scratch, but it would quickly go out of sync with our existing generator, as its internals may change quite a bit between minor releases. The advantage of a ScalaGenerator.scala would be that you could use Scala's string interpolation for templating. This will make generating Java code a lot easier. 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, > Are you aware of: http://www.jooq.org/doc/latest/manual/code-generation/codegen-daos > 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? > Well... Unit tests are battle grounds few have returned from and none of them victorious. I'd personally like to stay off that battle grounds for another while before someone can show me a very compelling solution to auto-generating unit tests (would they mock the DB? Or use H2? Or Use MockDataProvider? You'll have millions of flavours...) Having said so, if you show me: Why not :) 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. > I call that the Functional-Relational Impedance Mismatch 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/d/optout.
