Hi there,

I ran into a small problem with an entity that has a child collection and I reload it with data to ensure I have the latest copy of it and its children. (the user may or may not of edited the record or its children.)  I instatiate my entity, call a custom method to load a single record, then at a later stage call the load method again on the same instance and the child collection still contains the records from the initial load. 

I had assumed, wrongly I guess,  that a succesfull Query.Load would set any child collections to null, so that when you next reference the collection property on the entity it loads the child records again.  As I am using a custom load method I have simply set the child collection to null so not a problem to fix.  I realise I could have also recreated my object and loaded it rather than calling the load on the same instance a second time but that just feels wrong.

Is this behaviour by design? (Or am I going about this the wrong way? )

 Cheers

 Paul

Instantiating an entity or collection causes very little overhead. The preferred approach, by design, is that whenever you are loading from the database, you should think of that as a new object, and "new" it first. Perhaps it won't seem so counter-intuitive, if you consider that it, potentially, contains "new" data, and you do not want any left-over cached hierarchical sub-objects, or Where() clauses interfering.

---

David Neal Parsons
www.entityspaces.net

Thanks for the quick reply David.

I was in the client's office yesterday when I posted my question and it is an 80 mile journey home which gave me lots of time to think about it.  I did come to the conclusion that instantiating a new object is not so bad as the real performance cost is in loading the data which I am doing anyway.  Also changing the Query.Load method to determine which properties of an entity are child collections and setting them to null would not be straightforward.

The only problem I have now is making sure I haven't run foul of this somewhere else