Hi!

Is there a way to configure an entity to always use a given prefetchpath object? This could be useful in master-detail scenarios using a single datasourcebinding object.

Why is it that fields mapped on related fields (on m:1) are not prefetched by default using an (inner/outer) join? I think this wouldn't have a serious hit on performance since the user could explicitly select prefetched fields on design time or programmatically.

Thanks.

I don't believe it's offered in the designer or by default. Are you using adapter or self-servicing? You may be able to do this by modifying the templates. Are you using self-servicing or adapter?

Prefetches aren't done by default as it WILL hurt performance in the long run and you're then stuck with the prefetch even when you don't want to load the related entities. You can add it with little code to fetch the related entities, hence it's not done in the designer. Another reason is that related entities aren't 'part of' an entity, e.g. orders aren't part of 'customer'.

I see your point but what is then the pourpose of related fields? Are they just an alias? Wouldn't it be much more useful to have them prefetched using a join (as opposed to 2 or more SELECT statements fetching the entire related entities)? Maybe make the prefetch configurable in design time? The advantage of such a solution would be to have entities ready for databinding to a grid with no extra code plus the possibility to use business logic methods of the entity (advantage over typedlists). Either way, I think I'll be buying llblgen for the terrific product it is and the great support from your team

jungans wrote:

I see your point but what is then the pourpose of related fields? Are they just an alias?

They're not an alias, they refer directly to a field in a related entity. They're for databinding mostly.

It's a matter of the philosophy behind the code: does order.Customer belong to order or not? In the current design, no, it doesn't. This is an important thing: because Customer doesn't belong to order, it's THUS outside Order, and when fetching orders, you thus don't get customer automatically, unless you specify to fetch related entities (which are external to the entity to fetch!) as well, in the form of prefetch paths.

In the next upgrade to v2, v2.1 (all 2.x upgrades are free for v2.0 licensees of course), we'll add the concept of business components, which are aggregates of existing entities and which are usable as a single unit. Example: SalesOrder, which contains an order entity, a customer entity, an employee entity and a list of order items. These BC's then are fetched in 1 go, with prefetch paths. But more on that later.

Wouldn't it be much more useful to have them prefetched using a join (as opposed to 2 or more SELECT statements fetching the entire related entities)? Maybe make the prefetch configurable in design time? The advantage of such a solution would be to have entities ready for databinding to a grid with no extra code plus the possibility to use business logic methods of the entity (advantage over typedlists).

JOINs aren't always possible with these setups, as you can have multiple graph lines originating from the same entity. When we first implemented prefetch paths we looked at joins to implement the prefetch paths but it turned out not to be possible to formulate all graph fetches with joins efficiently.

Either way, I think I'll be buying llblgen for the terrific product it is and the great support from your team

Thanks!