My comments below: *Already done a while ago, found 2 bugs during the first 30 mins of use and figured out I still needed raw SQL for many non-select scenarios. There are not that many data access solutions that I haven't evaluated. I came from the .Net world 4-5 years ago and among others, I terribly missed llblgen which had IMHO achieved the best trade-off between usability, type-safety and SQL predictability. Before I knew about jooq, the java data access world could be summarized in 2 categories :* * * *1 - Raw SQL based or almost (jdbcTemplate, mybatis, dbutils), cumbersome, type unsafe, but predictable and efficient SQL* *2 - Pojo capable full OO object oriented solutions (hibernate, toplink), less hand coding but less predictable, ton of voodoo magic and "in-your-face" features* * * *Because I never trusted this "full OO domain over relational" approach advertised by bookwriters and saw a lot of projects where category 2 led to disaster, I choose "1" (mybatis) and had success doing so. Now I think that Jooq, thanks to its code generation approach does a great job reducing the drawbacks of category "1". I am just wondering if it could go even further with some common issues such as loading relations.* * * I have not found a ORM or SQL Mapping that fits my needs either (but jOOQ comes close :) ).
What I want is: 1. CRUD Immutable POJOs (that is all private fields are final with a constructor that fills them) 2. READ hiearchy of POJOs (that is Many to One's are loaded eagerly) but for WRITE only write the top POJO. 3. Once the POJO is loaded there is no magic. It is not "enhanced". It is safe to deserialize or cache. 4. Static (string) constants generated from the schema (column names, tables names) that I can use for custom SQL and Annotations. 5. Compile time Transaction Support through AspectJ 6. Transaction entity commit callbacks (if a row gets added I want an event generated). 7. Manually do One to Many (ie collections) which IMHO is the right way to do it (because there is nothing worse than accidentally pulling 1000 items). 8. Use plain SQL with the constants mentioned above. 9. Use JPA annotations to help map the SQL ResultSet to your POJOs 10. Threadsafe 11. Fluent API I discussed more here. http://stackoverflow.com/questions/2698665/orm-supporting-immutable-classes jOOQ does much of what I want but it cannot do #2, and sort of does #4, #8, and #9 (factories are not threadsafe). My inspiration comes some what from Anorm (plain SQL), EBeans (fetching children), MyBatis (Mapping), and jOOQ (Generating from Schema). * *
