Hi Joseph, Thank you very much for chiming in and providing feedback. It's always good to hear the opinion and insight from a new user. You're not yet biased by months of using jOOQ, and even if you might be missing something "obvious", it shows that it is obvious only for those accustomed to using jOOQ (so, e.g. the manual could be improved).
I'm commenting inline: 2016-01-03 23:53 GMT+01:00 <[email protected]>: > Hi > > I'm brand new to jOOQ, so maybe I'll be saying stupid stuff, don't > hesitate to tell me if so. > > Anyway, after having played with it various points came to me: > > A - my need is for a brand new use case, without existing tables. To start > from scratch is currently annoying. I need to create the tables and the > like, using string constants for names, and then generate the model, and > then update my tables creation script with the constants in the generated > classes. Yet I'm coming from Java and, actually, some Java model of my > domain. As such, it would be nice if, somehow, I could describe my tables > and then have the pojo generated and as well a creation script. So > basically I'm all for JPA annotations support, or something else if needs > be (I'm unsure JPA "philosophy" fits with jOOQ "all of SQL" concept, but > then one could complete the edge case on his own). > There are two ways to look at this. *1. From the dogmatic jOOQ philosophy point of view* JPA / Hibernate have won a lot in popularity precisely because they offer this "I-will-care-about-the-schema-details-later" approach. This is great for prototyping and (arguably) for the very beginning of a project. It's obviously the complete opposite of a good idea if you have a more complex domain, a pre-existing schema (e.g. you went to production already), or specific storage requirements. >From my personal experience, the latter is inevitable, so I tend to say that the little extra effort of writing correct DDL and to think about migrations from the very beginning of a project is an investment that pays off very quickly. >From a jOOQ perspective, it doesn't make sense to go the other way round, i.e. from POJOs to DDL, simply because POJOs are extremely primitive things, whereas DDL can be very sophisticated, and even the generated catalog / schema / table / column information is only a small subset of what you want to model in your database. You would lose on a lot of features (or conversely, we would have a lot of effort in re-implementing this part of JPA). *2. From a pragmatic "time-to-market" point of view* After the inevitable evangelism and dogma on this user group ;-) I can certainly see how advancing a project faster can be useful. So, if this is really the way to go for you right now, you could annotate your POJOs with JPA annotations, generate the DDL using Hibernate, and generate jOOQ artefacts using jOOQ. For this, you can use the org.jooq.util.jpa.JPADatabase from jOOQ-meta-extensions. I just realised that this isn't really documented. We'll fix this: https://github.com/jOOQ/jOOQ/issues/4892 The idea is described here. Vlad is the "developer advocate" at Red Hat for Hibernate. I'm sure, he'll appreciate your feedback: http://vladmihalcea.com/2013/12/06/jooq-facts-from-jpa-annotations-to-jooq-table-mappings Essentially, you'll have to configure the code generator like this: <database> <name>org.jooq.util.jpa.JPADatabase</name> <properties> <property> <!-- where your annotated entities are located --> <key>packages</key> <value>org.jooq.test.all.pojos.jpa</value> </property> </properties> </database> So, as an answer to this feature request: We're not going to move ahead with such an integration anytime soon in the future, as we don't want to implement JPA. The reason for this is mainly because existing JPA implementations are already very good, and using jOOQ together with JPA / Hibernate has been proven to work very nicely, both at code generation time (see above) as well as at runtime (see below): http://blog.jooq.org/2015/05/26/type-safe-queries-for-jpas-native-query-api 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? 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. 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. > Yes. Use <!-- Generate immutable POJOs for usage of the ResultQuery.fetchInto(Class) API This overrides any value set in <pojos/> Defaults to false --> <immutablePojos>false</immutablePojos> See: http://www.jooq.org/doc/latest/manual/code-generation/codegen-advanced 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) > For the others points, well, can't tell much apart from the obvious, so > I'll skip ;) > > Thanks a lot for jOOQ and hopefully it wasn't all nonsense! > Thank you for your useful feedback. It's always very good to learn about the expectations of new users. -- 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.
