New Posts New Posts RSS Feed: Cache and Related Entity (Lists)
  FAQ FAQ  Forum Search   Calendar   Register Register  Login Login

Cache and Related Entity (Lists)

 Post Reply Post Reply
Author
sbelini View Drop Down
IdeaBlade
IdeaBlade
Avatar

Joined: 13-Aug-2010
Location: Oakland
Posts: 786
Post Options Post Options   Quote sbelini Quote  Post ReplyReply Direct Link To This Post Topic: Cache and Related Entity (Lists)
    Posted: 05-Jul-2011 at 9:11am
Hi Markus,
You can explicitly set the EntityReferenceStrategy to DoNotLoad:
 
CodeEntity.PropertyMetadata.CodeTyp2List.ReferenceStrategy = new EntityReferenceStrategyEntityReferenceLoadStrategy.DoNotLoad, MergeStrategy.OverwriteChanges);
 
There's a topic in the DevForce Resource Center that will provide you with details.
 
Regards,
   Silvio.
Back to Top
mseeli View Drop Down
Newbie
Newbie
Avatar

Joined: 20-Sep-2010
Location: Switzerland
Posts: 31
Post Options Post Options   Quote mseeli Quote  Post ReplyReply Direct Link To This Post Posted: 05-Jul-2011 at 2:15am
I have a Silverlight application that can be configured with a large number of codes. Because they play such a important role in the application I load all of these codes at the start of the application into the cache so that later on I don't have to query them asynchronously anymore just to use a code.

I put all the different code types into one table and use inheritance to have different types of codes.
So all my codes inherit from CodeEntity and are in the table CodeEntities in the db.

At the start of the application I get all the entries  CodeEntities and make sure that they are all in the cache.

Some code types are related to each other (1:n relation).

Now I have noticed that when I navigate within these related codes (i.e. CodeTyp1.CodeTyp2List) DevForce re-queries the database even though all of the codes are already in the cache. 

Is this intended? When I set the default query strategy to CacheOnly I can suppress this behavior but I am hesitant to change the default query strategy all the time because I am not clear on the performance cost of such an action. Also I am afraid, that this could cause problems because of the asynchronous scenario (i.e. switching query strategy in one place while another query is still executing)   

Any ideas how to suppress all those needless db accesses?

Thank you  
Markus Seeli
Back to Top
 Post Reply Post Reply

Forum Jump Forum Permissions View Drop Down