Hello, N.B: I would like to invite other users on this group to participate in this interesting discussion!
> [Yes, I know it: it breaks OO's principles of separation of concepts > and layers] I don't mind that in generated source code. > [Yes, I know it: this breaks JOOQ's philosophy of "db is the the first > one"] Others have proven valid reasons to me, why this philosophy is not untouchable, even in the jOOQ world. Most importantly, Sergey Epik has suggested this several times on the user group, asking for a clean separation of what he called "introspection" and "generation" phases. This can be seen in the following thread: https://groups.google.com/d/topic/jooq-user/4-iZMVDtkGA/discussion > Advantages: > * Declaration of validation, persistence, and model in a unique place. That's what your database schema (from a jOOQ perspective) offers, too. A unique place for all your data model (including validation, constraints, etc.) > ** Development productivity enhancement, because all relevant code is > localized in one place, and apporting very little information. Who will generate the DDL / migration scripts from your annotated objects? Would you use Hibernate for that? I think you won't be able to have some parts of your domain being externalised to SQL scripts. > ** Bugs and errors (due to software layers synchronization > maintenance) probability reduction. I'm not sure what you mean by that > Disadvantages: > * Class model without inheritance. > * Class model relations are solely 1:1. True > It would possible implements an option in JOOQ that let to generate > the metamodel directly from JPA annotations in classes, without > connecting with DB? You could implement your own Generator. As a matter of fact, for what you want to achieve, you could even use Hibernate's code-generator along with velocity templates to generate jOOQ artefacts such as the schema and the tables. As a result of Sergey's requests, I have recently tried to dump the 13 supported databases as an INFORMATION_SCHEMA.xml, or TABLES.csv, COLUMNS.csv, REFERENTIAL_CONSTRAINTS.csv, etc. and read those files instead of reading from the database. This turned out to be a lot more work than I expected, if I want this type of source code generation to remain feature complete (including Routine, UDT, ARRAY support, etc) Generating source code from JPA/JSR-303 annotated beans is pretty much the same as generating source code from XML/CSV files, except that the domain model is no longer a SQL/relational one, but an object-oriented one. I like those ideas, but when you go in-depth, they become very hard to do right. For instance, what if your JPA-annotated model uses inheritance? What if your JPA-annotated model uses @JoinTable, @DiscriminatorColumn, @Embeddable, @Embedded, @IdClass, @CollectionTable, @Enumerated, etc. etc. jOOQ could quickly support simple code generation from @Table, @Column and other simple annotations. But once that's in place, users would expect more and perceive things not to be working correctly. Is that worth the trouble? The question goes to the whole user group. So before we continue this discussion, please tell me why you prefer jOOQ over Hibernate / QueryDSL and other tools that already implement JPA, when you don't want to place your main data schema authority in the database? Note, some users have successfully used jOOQ and Hibernate together (Hibernate for the CRUD and some simple queries, jOOQ for the "hard-core" SQL). Isn't that a more suitable approach for you, right now? > Or, better: It would be possible to check both sides: annotations > and DB schema! If there would be differences, then generator alerts > to user! Hehe, yes. Looking forward to pull requests! ;-) Cheers Lukas 2012/5/31 Pedro Pastor <[email protected]>: > JOOQ offers this: > * > "jooq-codegen configuration" > <!-- Annotate POJOs and Records with JPA annotations for increased > compatibility and better integration with JPA/Hibernate, etc > Defaults to false --> > <jpaAnnotations>false</jpaAnnotations> > * > "Generated or custom POJO's instead of jOOQ's Records" > If you're using jOOQ along with Hibernate / JPA, or if you want to > use your > own, custom domain-model instead of jOOQ's Record type-hierarchy, you > can > choose to select values into POJOs. Let's say you defined a POJO for > authors: > But, I want this: > > I would like to INTEGRATE my domain class, the validation/restrictions > declaration (annotations) of that class, > and the persistence metadata (annotations) of that class in one place: > the SAME domain class. > [Yes, I know it: it breaks OO's principles of separation of concepts > and layers] > > I would like that JOOQ metamodel generator takes that domain class, > analize it, and generate > the corresponding JOOQ classes, based on the presistence annotations. > So, there will NOT be > connection to a database. > [Yes, I know it: this breaks JOOQ's philosophy of "db is the the first > one"] > > For the validation/restrictions declaration I was think in Bean > Validation (JSR 303), although it's > a transparent thing for this situation. > For the persistence metadata, I was think in JPA 2.0 (JSR 317), > although I would serve any basic > annotation of kind of @Table, @Column, etc. It would be a simplified > JPA: no @Entity, no @ManyToMany, > etc. We need the minimal information to generate the JOOQ metamodel. > > Advantages: > * Declaration of validation, persistence, and model in a unique place. > Therefore: > ** Development productivity enhancement, because all relevant code is > localized in one place, and apporting very little information. > ** Bugs and errors (due to software layers synchronization > maintenance) probability reduction. > Disadvantages: > * Class model without inheritance. > * Class model relations are solely 1:1. > > > CONCLUSSION: > > It would possible implements an option in JOOQ that let to generate > the metamodel directly from JPA annotations in classes, without > connecting with DB? > Or, better: It would be possible to check both sides: annotations > and DB schema! If there would be differences, then generator alerts > to user!
