Comments on: Viewing Generated Proxy Code in the Entity Framework http://davedewinter.com/2010/04/08/viewing-generated-proxy-code-in-the-entity-framework/ Just another WordPress site Thu, 22 Sep 2011 22:12:08 +0000 hourly 1 http://wordpress.org/?v=3.2 By: David DeWinter http://davedewinter.com/2010/04/08/viewing-generated-proxy-code-in-the-entity-framework/#comment-198 David DeWinter Sun, 21 Nov 2010 19:25:09 +0000 http://blogs.rev-net.com/ddewinter/?p=304#comment-198 Hi Peter, sorry for the delay in replying. The underlying problem is that there is no way for the EF to know there is new data in the database unless you tell it (e.g. with OverwriteChanges). It's an interesting situation that you bring up because I can see advantages to both sides. On the one hand, you could expect that reloading an object with MergeOption.OverwriteChanges would cause navigation properties to be invalidated and thus lazy loading would trigger a new query against the database, even if the navigation property was already loaded. On the other hand, this behavior could be surprising because you are only loading the object with MergeOption.OverwriteChanges and not the association. You do have a way to do explicit loading of associations with MergeOption.OverwriteChanges (by using ObjectContext.LoadProperty). But I don't think there is a way to tell lazy loading what MergeOption to use at this time. Hi Peter, sorry for the delay in replying. The underlying problem is that there is no way for the EF to know there is new data in the database unless you tell it (e.g. with OverwriteChanges). It’s an interesting situation that you bring up because I can see advantages to both sides. On the one hand, you could expect that reloading an object with MergeOption.OverwriteChanges would cause navigation properties to be invalidated and thus lazy loading would trigger a new query against the database, even if the navigation property was already loaded. On the other hand, this behavior could be surprising because you are only loading the object with MergeOption.OverwriteChanges and not the association.

You do have a way to do explicit loading of associations with MergeOption.OverwriteChanges (by using ObjectContext.LoadProperty). But I don’t think there is a way to tell lazy loading what MergeOption to use at this time.

]]> By: peterno http://davedewinter.com/2010/04/08/viewing-generated-proxy-code-in-the-entity-framework/#comment-197 peterno Mon, 06 Sep 2010 13:02:35 +0000 http://blogs.rev-net.com/ddewinter/?p=304#comment-197 Hi, we have problems that our navigation propterties are not not reloaded even if we have set MergeOption.OverwriteChanges on the ObjectSet. The fist time we fetch a entity and then access its navigation propterties we get the data (and we can see this in EFProf). I we then make changes to the database and fetch the the entity again we see that the actual entity is fetched from the database with its new data. But when we access the entity's navigation property the already loaded data is returned and not the updated data in the database. You state above that "we will load the navigation property into memory if it’s not there already." How does it handle the case that the data is memory but the data in the database is updated and thereby the data should be fetched again into memory? BR, /Peter Hi, we have problems that our navigation propterties are not not reloaded even if we have set MergeOption.OverwriteChanges on the ObjectSet. The fist time we fetch a entity and then access its navigation propterties we get the data (and we can see this in EFProf). I we then make changes to the database and fetch the the entity again we see that the actual entity is fetched from the database with its new data. But when we access the entity’s navigation property the already loaded data is returned and not the updated data in the database.
You state above that “we will load the navigation property into memory if it’s not there already.” How does it handle the case that the data is memory but the data in the database is updated and thereby the data should be fetched again into memory?

BR,

/Peter

]]> By: David DeWinter http://davedewinter.com/2010/04/08/viewing-generated-proxy-code-in-the-entity-framework/#comment-196 David DeWinter Sat, 03 Jul 2010 01:28:31 +0000 http://blogs.rev-net.com/ddewinter/?p=304#comment-196 Dinesh, did you use the first code snippet to set the AssemblyBuilderAccess to AssemblyBuilderAccess.RunAndSave instead of AssemblyBuilderAccess.Run? Dinesh, did you use the first code snippet to set the AssemblyBuilderAccess to AssemblyBuilderAccess.RunAndSave instead of AssemblyBuilderAccess.Run?

]]> By: Dinesh http://davedewinter.com/2010/04/08/viewing-generated-proxy-code-in-the-entity-framework/#comment-195 Dinesh Tue, 15 Jun 2010 23:02:50 +0000 http://blogs.rev-net.com/ddewinter/?p=304#comment-195 Hi, I tried this solution (took the code from here pretty much as is) but keep getting an InvalidOperationException with the message "Cannot save a transient assembly" on the pocoProxyAssembly.Save(...) line. I am running it through a Visual Studio Unit Test though. Hi, I tried this solution (took the code from here pretty much as is) but keep getting an InvalidOperationException with the message “Cannot save a transient assembly” on the pocoProxyAssembly.Save(…) line. I am running it through a Visual Studio Unit Test though.

]]> By: marius http://davedewinter.com/2010/04/08/viewing-generated-proxy-code-in-the-entity-framework/#comment-194 marius Mon, 24 May 2010 15:29:32 +0000 http://blogs.rev-net.com/ddewinter/?p=304#comment-194 Thx!Thx!Thx! Thx!Thx!Thx!

]]> By: Muhammad Mosa http://davedewinter.com/2010/04/08/viewing-generated-proxy-code-in-the-entity-framework/#comment-193 Muhammad Mosa Fri, 09 Apr 2010 10:04:59 +0000 http://blogs.rev-net.com/ddewinter/?p=304#comment-193 What a valuable post! Thank you for taking the time to explain this subject. And to show in practical and give us the chance to dig inside. Very cool. Thank you again. What a valuable post! Thank you for taking the time to explain this subject. And to show in practical and give us the chance to dig inside.
Very cool. Thank you again.

]]>