5 Answers, 1 is accepted
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
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.
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
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.
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.
Petar
the Telerik team