Hi Stéphane, 2013/8/6 Stéphane Cl <[email protected]>
> Hi lukas, > I used llblgen before linq came out, at this time, there were many > commercial ORMs available and nhibernate was there as a free alternative. > Unlike in the java world, non free frameworks are quite popular and > developers don't mind paying for useful stuff. > I think the Java world wouldn't mind paying for some useful stuff either. Sometimes, I get the feeling that much of (Free!) Open Source will lead to a big long-term maintenance nightmare for consumers / developers. While getting quite a few reads, I didn't get many comments on this article, unfortunately: http://java.dzone.com/articles/10-reasons-not-choose > What I liked most about llblgen was it's stongly typed querying API which > was a direct benefit of code generation (just like Jooq). > Being more SQL focused, jooq would have been a slightly better tool for > writing complex queries and fetching tabular data. > > Llblgen chose an higher level of abstraction but without abusing the POJO > principle, chose a mix between object and SQL, went further in handling > relationships and graphs. > > Here is an exemple taken from their current documentation about how you > would load a collection of Customers, along with Their Address and a > collection of orders > > // QuerySpec alternative > var customers = new EntityCollection<CustomerEntity>(); > using(var adapter = new DataAccessAdapter()) > { > var qf = new QueryFactory(); > var q = qf.Customer > .Where(CustomerFields.Country=="Germany") > .WithPath(CustomerEntity.PrefetchPath.Orders > > .WithSubPath(OrderEntity.PrefetchPathOrderDetails), > CustomerEntity.PrefetchPathVisitingAddress); > adapter.FetchQuery(q, customers); > } > > > Notice the .WithPath parameter... > The framework would then load the Customers, and then fill the Order > relationship using a second query, with either an SQL IN or an EXISTS > subquery depending on how much customers were returned. > I see. It's like a proprietary JOIN syntax. If I get this correctly, the "WITH PATH" syntax will join dependent entities producing nested tables for every result customer, instead of duplicating customer entries... I think that something like this would be interesting for jOOQ in the long run. Let's put that on the roadmap: https://github.com/jOOQ/jOOQ/issues/2679 Here is an example that goes even further : > > var employees= new EntityCollection<EmployeeEntity>(); > using(DataAccessAdapter adapter = new DataAccessAdapter()) > { > var qf = new QueryFactory(); > var q = qf.Employee > .WithPath(EmployeeEntity.PrefetchPathOrders > > .WithOrdering(OrderFields.OrderDate.Descending()) > .WithLimit(1)); > adapter.FetchQuery(q, employees); > } > > > Of course you can do that using Jooq too, but you'll write the queries > yourself and implement a nice, non reusable algorithm for populating your > graph but let's face it, everyone hates writing that kind of code. I do > that many times a day, and that's the reason why I am still using hibernate. > True. > Below is an interesting feature for Jooq : > > using(var adapter = new DataAccessAdapter()) > { > var qf = new QueryFactory(); > var q = qf.Order > > .From(QueryTarget.InnerJoin(OrderEntity.Relations.CustomerEntityUsingCustomerId)) > .Where(CustomerFields.CustomerId==myCustomer.CustomerId); > adapter.FetchQuery(q, myCustomer.Orders); > } > > > Notice the OrderEntity.Relations.CustomerEntityUsingCustomerId which is a > generated object... > Wouldn't that be nice to have FK-based relations in the jooq Table classes > and be able to pass them to the join(..) method in the query DSL rather > than relying on join(X).onkey() ? > The onKey() syntax supports referencing explicit foreign key references, e.g. TABLE_A.join(TABLE_B).onKey(GENERATED_FOREIGN_KEY_REFERENCE); Maybe this feature is not visible enough, from the docs? But it would probably be nice to avoid redundancy by omitting TABLE_B entirely, e.g. TABLE_A.joinOnKey(GENERATED_FOREIGN_KEY_REFERENCE); I'll just put that up on the roadmap as well: https://github.com/jOOQ/jOOQ/issues/2680 To conclude I'd say that llblgen is a good showcase of what a data access > solution can do without reyling on osbcure concepts. > I don't think we can ask Jooq to do the same things, they are both > different tools, but some help when dealing with graphs would greatly > complement it and as shown above, it may be possible to do without > implementing a crazy caching mechanism. > I agree. The added value is obvious, and these features don't contradict jOOQ's mission as they are still very "relational". Should jOOQ ever be ported to C#, it would be good to have the right features ready to compete with LLBLGen Pro Thanks a lot for your insight! Cheers Lukas -- 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/groups/opt_out.
