Hi guys, Just a short note from me on this interesting discussion. While I won't delve into the Hibernate pros and cons ;-), I'll happily discuss LLBLGen on this user group with you. I have found it to be quite similar to jOOQ, in various aspects. It's good to see that C# also leaves room for a tool like these, even if C# has LINQ. C# developers tend to love LINQ-to-Objects for its conciseness, similar as I expect Java developers loving the new Java 8 Streams API combined with Lambdas.
But there is a lot of controversy towards LINQ-to-SQL, which shows another type of impedance mismatch in such approaches. That of an API trying to abstract a querying language in to a "higher-level" language (e.g. LINQ, JPQL), omitting many of the underlying technology's features (SQL). I've blogged about this mismatch here: http://blog.jooq.org/2013/07/01/linq-and-java Feel free to extend this discussion to a SQL/jOOQ to HQL/JPQL comparison :-) Anyway, I'm glad that you outline the pros of LLBLGen. I'd be very curious about other good aspects of that framework, since you've made experience with it! Cheers Lukas 2013/8/5 Stéphane Cl <[email protected]> > Hello, > > I guess both the hate and the misuse come from misrepresentation. The >> "Hibernate in Action" book even goes to great lengths to explain how to do >> "long-running conversations that span multiple transactions". >> >> > Does it? I can't even imagine myself manipulating detached, explosive > objects. > > >> That's yet another issue. You can't use stored procedures if you want to >> keep migration costs under control. Or, put another way: If you use stored >> procedures, you should keep the business logic in the database, and then >> any shitty ORM will do and you don't need Hibernate that much anymore. >> (...) Hibernate also doesn't even begin to handle bulk queries (...) >> > > Well, I am not a big fan of writing and maintaining stored procedures but > sometimes it's the best way to handle bulk operations. > It's a bit like comparing DOM and SAX, you use one when you can, the other > one when you have to. > > >> Sounds intriguing. >> Are there any whitepapers around? >> > > Not sure, it has been a while since I left my previous job and I haven't > used it since then. > It generated record classes that were somewhat similar to Jooq, along with > a representation of their relationships. > > Some info about fetching graphs can be found here (it's an old version, I > am sure it has become much easier): > > http://www.llblgen.com/documentation/2.6/Using%20the%20generated%20code/Adapter/gencode_prefetchpaths_adapter.htm > > At loading time, you could basically tell the framework which branches of > the object graph should be pre-loaded , this could go to any depth. > For example, from an OrderDetail entity it was possible to branch Order, > from there you could branch Customer, then Address, Country, anything, the > framework would then take care of efficiently filling the graph using > either SQL IN clauses or Subqueries. > > > > -- > 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. > > > -- 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.
