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.
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.
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.
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() ?
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.
Le mardi 6 août 2013 10:06:10 UTC+2, Lukas Eder a écrit :
>
> 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] <javascript:>>
>
>> 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] <javascript:>.
>> 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.
