HI, On Tuesday, September 18, 2012 10:34:55 PM UTC+2, Lukas Eder wrote: > > > I'm not sure what you mean by "dedicated collection classes". Could > you elaborate this idea? It might just correspond to this old feature > request here: > https://github.com/jOOQ/jOOQ/issues/345 > > Yes, in some way... Dedicated collection classes may then have some relation based methods to enable fetching relations in a single query.
LLblgen, a very famous commercial ORM in the .net world based on code generation used such syntax : CustomerCollection customers = new CustomerCollection(); //Relations to load (customer -> orders -> orderdetails and customer -> Address) IPrefetchPath prefetchPath = new PrefetchPath(); prefetchPath.Add(CustomerEntity.PrefetchPathOrders).SubPath.Add(OrderEntity.PrefetchPathOrderDetails); prefetchPath.Add(CustomerEntity.PrefetchPathAddress); //query filter IPredicateExpression filter = new PredicateExpression(); filter.Add(CustomerFields.Country == "Germany"); DataAdapter.GetMulti(filter, prefetchPath); //data adapter is equivalent to the Factory The orm would load the main collection and its filter, then visiting the prefetchPath graph, it would issue SELECT IN (x,x,x) or SELECT IN (SELECT ...) depending on the number of entries returned. It was all type safe, generated code, no type-unsafe HQL strings or proxy-based magic. I have spent some time investigating the idea, finding it > quite non-trivial to implement. Any ideas, hints are very welcome, > though! > There is certainly not an easy and definitive solution to this, other SQL based data access solutions such as Mybatis have exactly the same problem. *I got many to one to sort of work using JPA annotations (@ManyToOne + @JoinColumn) and the ResultSetMetaData to figure out how to transform the child object from the ResultSet.* *One to many and many to many will be a PITA and in my mind defeats the goals of jOOQ.* *If that feature (child fetching) interests you should check Ajave Ebean. * 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.
