This is a migrated thread and some comments may be shown as answers.

Specify default load behaviour for related objects/collections

5 Answers 182 Views
Getting Started
This is a migrated thread and some comments may be shown as answers.
This question is locked. New answers and comments are not allowed.
AndreaT
Top achievements
Rank 1
AndreaT asked on 27 Oct 2010, 12:22 PM
Hi

i would like to set to lazy the default load beviour for all entities. Where can I programmatically set this?

best regards
Andrea

5 Answers, 1 is accepted

Sort by
0
Petko_I
Telerik team
answered on 01 Nov 2010, 07:35 PM
Hi AndreaT,

By default all of the loading OpenAccess does is lazy. You do not have to explicitly set it. However, you can force eager loading of persistent objects with the new Fetch Optimization API. Can you tell us if you observed a scenario where the loading was not lazy by default?

Kind regards,
Petko_I
the Telerik team
Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items
0
stibiub
Top achievements
Rank 1
answered on 13 Feb 2013, 07:58 AM
Hello,

A related question: can the lazy loading be disabled? Either globally, per entity or per relation?
This would mean that some relations will remain null/empty unless they are fetched eagerly.

Thanks.
0
Thomas
Telerik team
answered on 13 Feb 2013, 12:55 PM
Lazy loading can be avoided by specifying a reference or collection field as belonging to the default fetch group. However, why would you do this? This is a compile time setting, and using FetchPlans is much more flexible at runtime.
Just to clarify this: Because a reference or collection is loaded lazily this does not mean that the user visible instance of the collection is filled with null; it just means that it is fetched from the database when it is acutally needed. Because our enhancer allows to detect  field accesses on persistent classes we can do late fetches when the reference / collection field content is actually requested by the application. Lazy loading will then fetch the data from the server; eager loading will have the data fetched already when the surrounding object is fetched and reuse the data that is already present in the client. In both cases a reference or collection instance will be returned upon field access.

Regards,
Thomas
the Telerik team
Q3'12 SP1 of OpenAccess ORM packs Multi-Table Entities mapping support. Check it out.
0
stibiub
Top achievements
Rank 1
answered on 14 Feb 2013, 11:58 AM

Hi Thomas,

Thanks for responding.

The problem I have is a bit broader.

We are sending our entities with WCF services to other layers. So the entities get serialized. 

Upon serialization all the related entities are loaded and serialized. This is as problem because I want to control which related entities to load and which to remain not loaded (null references or empty lists) because different services need different amount of data - for the same entity.

On short I need to control the amount of data fetched for an entity and then send it via WCF.

So what I tried to do is: load some of the relations eagerly (with Fetch API). And to avoid too many Joins I use Lazy Loading for some other relations. I trigger the loading by accessing the corresponding navigation properties. This is fine. The problem is that when the entity gets serialized the entire graph is fetched, including props that are not loaded and I don't need for this service and their relations too.

One option would be to pass the detached copy (with CreateDetachedCopy) but this does not do a deep copy so I loose fetched related entities. Actually, if I pass in also the fetch strategy the detached copy will have those relations loaded. But I still lose the relations that were lazy loaded in the original entity.

How do you recommend to handle this scenario?

Thanks. 

0
PetarP
Telerik team
answered on 19 Feb 2013, 11:52 AM
Hi stibiub,

 The only option you have is to use the CreateDetachedCopy method as you have already figured out. The only difference is that you will need to not only specify the fetch strategy for your root object but the strategies for the child objects as well. For example if you have an object reference as follows : Order has Products and each Product has a category you can specify your fetchplan to include all Products for a given order and then to include all categories for each product. Applying that in the CreateDetachedCopy method will fetch the entire graph.

Regards,
Petar
the Telerik team
Q3'12 SP1 of OpenAccess ORM packs Multi-Table Entities mapping support. Check it out.
Tags
Getting Started
Asked by
AndreaT
Top achievements
Rank 1
Answers by
Petko_I
Telerik team
stibiub
Top achievements
Rank 1
Thomas
Telerik team
PetarP
Telerik team
Share this question
or