Print Page | Close Window

EntityServerSaveInterceptor strategy

Printed From: IdeaBlade
Category: DevForce
Forum Name: DevForce 2010
Forum Discription: For .NET 4.0
URL: http://www.ideablade.com/forum/forum_posts.asp?TID=2200
Printed Date: 26-Mar-2025 at 2:09am


Topic: EntityServerSaveInterceptor strategy
Posted By: mikewishart
Subject: EntityServerSaveInterceptor strategy
Date Posted: 28-Sep-2010 at 10:15am
I have a question about EntityServerSaveInterceptor and the strategy when working with entities in the ExecuteSave() method.

In our application, it's multi-tenant and so the IDataSourceKeyResolver implementation requires a keyExtension for the client database with a specific keyName.

In the ExecuteSave(), I'm trying to update some child entities of a transaction.  For instance, Order.Item.ItemHistories where the ExecuteSave() method is determining the print number for the Order and must also update a description string in the history records.

It seems like since the Item will have been modified, it's not entirely in the entity graph as the EM tried to lazy load the item and in doing so it requested a key from the IDataSourceKeyResolver but with a blank keyExtension.

So, my question is, is it best to avoid navigation properties and just look for child elements (for example em.FindEntities(ItemHistory, EntityState.Added).Where(e => e.ItemId == order.ItemId)?  This avoids any possibility of lazy loads.  Or, is there a way to prevent the entity manager from trying to do lazy loading in the EntityServerSaveInterceptor? What's the best practice here?

Thanks,
Mike


Replies:
Posted By: DenisK
Date Posted: 29-Sep-2010 at 2:18pm
Hi Mike;

1. "In the ExecuteSave(), I'm trying to update some child entities of a transaction............It seems like since the Item will have been modified, it's not entirely in the entity graph as the EM tried to lazy load the item"

Assuming that you have called SaveChanges(), without passing any particular entity to be saved, the EM inside the save interceptor will contain all of the Added, Modified and Deleted entities from the client. This also includes all the Added, Modified, Deleted, related items. This means that the EM should not try to lazy load your Item. Are you saying that it does try to lazy load?

2. Regarding the best practice to prevent lazy load, the simplest way is to make the EM DefaultQueryStrategy to CacheOnly. If you need to retrieve data from the data source, then you can write a query with a With(QueryStratergy.DataSourceOnly) clause.

Hope this helps,

Denis


Print Page | Close Window