Hi,

let's assume we have three entities (Customer, Invoice, InvoiceItem) with a 1:n realation ships each:
Customer-> Invoice -> InvoiceItem

Currently, the "left join fetch" hint in the HQL query will generate a join fetch, but works only one level deep.

If i have query by customer attributes only, i would prefer a table-by-table hopping strategy for the loading:
o find all Customer's matching the query
o load all Invoice's by customer_id
o load all InvoiceItem's by invoice_id

gavin: is it political correct to request such a feature? Is it feasible?

Bye,

J

If I understand you correctly this is what is called fetch profiles.

It is being discussed - but the jury is still out on it ;)

Put it on the JIRA and see if people vote for it....

+1 on this feature

(not yet posted on JIRA - I'll repeat my vote once inserted!)

What would be nice - is to be able to specify the load profile when executing the initial Query (the one that lookup/load the Customer in the example above).

Something like execute my query, taking this load profile into account... This would allow to use different load profile depending on the situation (but still the same object model and mapping).

Sounds silly ?

as I said...that's all what fetch profiles are about ;)


And I give my +1 for this stuff also ;)

I do not understand what is being asked for here? How is this related to fetch profiles? sounds more like batch fetching to me, which is already implemented in 2.1.

Well, i know 2.1b4, and what i request is not in there.

From my current understanding, the only deep eager loading strategy is the left join with the FETCH keyword, as it was pointed out by gavin in
http://forum.hibernate.org/viewtopic.php?t=634

What i want is something different:

o the initial query finds all entities of the first entity class/table (Customer in the example)
o the next query will use all ids of Customer and query the next entity class/table (Invoice in the example) by the Invoice's foreign key customer_id
o the next query will use all ids of Invoices and query the next entity class/table (InvoiceItem in the example) by the InvoiceItem's foreign key invoice_id
o at the end, all objects are connected

The current left join loading generates one SQL statement (which is good), but i want to say
o this keys/objects are the starting point of my object graph,
o find the rest of the graph (not all 1:n collections, but only the one i need for that query) and
o load the objects with one SQL query per table


I was in a project that used (and needed) that strategy in a high performance ticket system (the links are only in german, sorry):
http://www.sdm.de/download/publikatione ... masuch.pdf
http://www.sdm.de/de/unternehmen/refere ... .php?ID=56

This functionality exists.


set batch-size="10" or whatever.

Sorry, it's not what i requested: i need that per query, not per class.

Why?

Because eager loading is a dangerous thing: sometimes i need just i tiny fraction of the object graph, end lazy loading rules, but sometimes i need the whole object graph, so in that query i want to say: slurbe mode on;-)

So use batch-size in combination with lazy loading proxies, as is intended.

For me, it feels much more natural that i specify special loading strategies on a query and not in the infrastructure.
It's also much easier to understand and document, but i know that it is harder to implement under the hood.

Correct, it is much more difficult to implement and I see no reason why it would perform any better. We will not implement this feature. batch-size is nicer, simpler and much easier to explain to the user.

It will not perform better, but from looking at the query code, the programmer has a much better understanding why a certain query generates the SQL code it generates.


:-(


I didn't understand it, and again, from looking on a query i never will understand the actions that will occur.
I like the "determistic" behaviour of HQL, so i could always say what a given query costs. With batch-size it's much harder to understand without trying, and some things will AFAIK never work
(e.g.: one query that loads all invoices but no invoice items in one SQL statement and one query that load all invoices with all invoice items in two SQL statements).