Hi Lukas Thx for your nice and thorough answer :)
Answers inline. >> A - my need is for a brand new use case, without existing tables. To >> start from scratch is currently annoying. (snip) >> > > There are two ways to look at this. > > *1. From the dogmatic jOOQ philosophy point of view* > (snip) > > *2. From a pragmatic "time-to-market" point of view* > (snip) > to make it short : I fully agree. I thought of the hibernate generation upfront, but then the pojo wouldn't be of any help afterward, so it turned me off. maybe I should explicit a bit more my pain point : when I write the first migration (or any migration adding new/changing stuff), I've to resort to strings. Which then are duplicates of the content in the generated model. This annoys me a bit in terms of "type safety" and more general usability: if I add the foo column in a migration, then going at the foo definition in the model and looking for usage/reference wouldn't show the string "foo" in the migration script. Bad. Currently I'm thinking of updating post model generation the migration script. Tedious, error prone and definitely not sexy ^^. So I'm looking for alternatives. > B - even without going as far as A, when the model is generated from DB it >> would be nice to have the creation script created too. >> > > > Hmm, which creation script do you mean? > The DDL queries to create the data structure present in the generated model. > > There is a pending feature request to re-generate the DDL from what the > jOOQ runtime schema model knows about the underlying schema: > https://github.com/jOOQ/jOOQ/issues/3160 > > This would be useful for those who like to duplicate a schema on H2 or > some other in-memory database. > And to start using migration in a pre existing DB. Or to replace the existing non type safe migration script with a type safe one. If I got your issue right, one could even dream of being able to say "generate me the whole DDL" or "generate the DDL for the delta between this schema and the previous one. Which would rock like hell :) Actually to me it sounds pretty tricky impl wise, am I right? > C - immutable POJO: I really like the peace of mind immutable objects >> provide. It would be awesome if I could tell the generator to create >> immutable pojos only. >> > > (snip) > See: > http://www.jooq.org/doc/latest/manual/code-generation/codegen-advanced > my bad ^^ Shouldn't immutable pojo be the default? ^^ > > Regarding your others questions : >> 1 - target languages, forms >> IMHO the generated code is tightly coupled to the DSL itself. So to me it >> feels like the question is more about the whole lib than just the pojo. >> Still, being written in Java, it should be usable from most of the others >> JVM languages. Maybe going for an immutable approach would help for >> integration with Clojure or Scala code, but once again then is about the >> whole public API then, which is quite bigger from the generator itself. >> > > Indeed, but there are quick wins here. For instance, in Scala, a case > class is more idiomatic than (yet, not that different from) a "POJO". Also, > I'm still hoping that we're getting the Int vs. java.lang.Integer thing > right, eventually (although there are some caveats) > Well, you're the judge here. I would prefer Query[] queries = ctx.ddl(mySchema); a thousand times, and scalaists just as well I guess ;) On top, to do "anti corruption layer" is always a good practices and way easier in Scala, so maybe scalaist can wrap/bridge the way they want some nicely done pojos ;) I'm kidding to be honest. I would love case classes if using it in Scala. What's the issue with Int vs. java.lang.Integer ? But still, the more languages you add the more issues like this you'll encounter. At the expenses of core crazy functionalities, whereas both Scala and Clojure are very proud of their ability to use Java code, so... In the end generating some platform independent data structure sounds like a nice goal. Once this is done, anyone could marshal it to its one language without fiddling with jooq's core. Pretty nice IMHO. Cheers joseph -- 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.
