Force entity framework to load new data from database without disposing the context

desanti

Sorry , I think this is a problem of Entity Framework Design. Because , if other users add or delete records , when I run my query these changes are "known" by EF and are reflected in results. But the updated records are not read from database and old values are kept from local cache. For me , It's ridiculous that EF does not have a command to "READ ALL THE DATA AGAIN FROM DATABASE"

Dave Kreskowiak

Those changes are NOT known by EF. At least not until you run a query again to retrieve the entire set of records again. But now you have a problem. How does EF know that the records are deleted? It doesn't. The records just don't show up in the result set from the database. That in no way means that they were deleted. The only way to know that would be to get the record ID of what EF has cached and try to retrieve that record ID from the database. Now do that for every record you have cached and it'll take a long time. Move on to the problem of just telling EF to reload a specific table. Great, you now have all of the data from that table, but how to do handle the case where the cached data is "dirty"? That means you have data in the cache that's been modified but not written back tot he database. Do you through those changes out in favor of the current data? Do you skip that changes? Do you modify only certain fields? How is the ORM supposed to know which fields to keep and which to throw out and refresh? Another problem. What query returned the data the generated the object in the cache? There is ORM that I'm aware of that caches the query that generated a set of object graphs. What if there's multiple queries that can be run that generate a particular object in a graph? How do you know which query to run to PROPERLY regenerate that object with the correct data? It's impossible for the ORM to know that. Google "database concurrency" for the difficulties in doing what you want to do. There is no easy solution to this problem, and not every solution is going to work for every application. You're looking at this through the lens of what you want EF to do and not from the standpoint of how any ORM would even accomplish this in a generic way usable by all applications. I know you just want to call .Reload() and have it work, but you're not seeing the complexity behind actually making that happen.

Asking questions is a skill CodeProject Forum Guidelines Google: C# How to debug code Seriously, go read these articles.
Dave Kreskowiak

desanti

Quote:

How does EF know that the records are deleted? It doesn't. The records just don't show up in the result set from the database.

Ok , and why EF does not keep the records that are in local cache , but instead "use the information" that those records are not show up in the result set of database ? And why in the case of modified records , "the information from database" is not used , and it's just keep the records from local cache.

Quote:

Move on to the problem of just telling EF to reload a specific table. Great, you now have all of the data from that table, but how to do handle the case where the cached data is "dirty"?

If the cached data is modified , i think EF should let the programmers to choose . If i try to reload data from database when cached data is modified , then i'm responsible to get the new data from database and overwrite those changes. But In my application for example , if a modification was made , i don't let the users to reload data from database. It's simple. And how you will resolve the problem when cached data is modified and i create a new context ( as many have suggested this idea for my problem). This is the same problem. I think these problems EF should leave in the hand of programmers.

Dave Kreskowiak

Quote:

Ok , and why EF does not keep the records that are in local cache , but instead "use the information" that those records are not show up in the result set of database ? And why in the case of modified records , "the information from database" is not used , and it's just keep the records from local cache.

That made no sense at all. EF maintains a cache of objects reconstituted from result sets returned by the database. Once the result set is returned, there is no connection between the objects and the database. If the database changes, EF gets no notification at all that anything happened to the database copy. If you have modified records, EF maintains the original "as loaded" copy of the object and the modifications to it. When EF goes to update the records in the tables, all of the original field values go into the WHERE clause of the SQL DELETE OR UPDATE statements. If any of those fields do not match the current data in the fields in the database table, the query fails to update the record because of a concurrency problem. You're not updating the latest version of the record. You're trying to update a newer version of the record than what you retrieved. That is a problem not solved by EF or the database. Seriously, go Google "database concurrency" and start reading.

desanti wrote:

If the cached data is modified , i think EF should let the programmers to choose

And how do you propose you do that in the EF code? EF avoids the problem by not handling it at all, letting YOU decide how to handle it, which is why you even asked this question in the first place because of performance. Having EF do it internally will not make it any faster. It still has to same limitations you do handling it yourself, row-by-row from the cached data. There is no solution to the performance problem! Again, your only chance at making either of the two solutions "faster" is to cache less data at the client.

Asking questions is a skill CodeProject Forum Guidelines Google: C# How to debug code Seriously, go read these articles.
Dav

desanti

Quote:

And how do you propose you do that in the EF code? EF avoids the problem by not handling it at all, letting YOU decide how to handle it, which is why you even asked this question in the first place because of performance. Having EF do it internally will not make it any faster. It still has to same limitations you do handling it yourself, row-by-row from the cached data.

With "Letting in the hand of programmers" , i mean informing them some rules , that if the local data is modified and they try to load from database , the local cache will be overwritten. So before loading from database , save or Undo those changes , but if you want to do without save or undo , you will loose those changes. I think is simple . The police does not close the road for people because there are cars moving on it. But there are semaphores and people are informed that when the semaphore is green the can walk safely, if is red they should not walk but they are free to do , keeping the risk by itself.

Dave Kreskowiak

desanti wrote:

hat if the local data is modified and they try to load from database , the local cache will be overwritten

So is that behavior desirable in all applications and situations? Nope. So how do you configure that behavior in code, and all possible variants? Like either keeping the modified data, dumping all the modified data, or just keeping some of it and replacing the rest, or replacing some of it based on rules, or dumping some of it based on rules, ... there's too many possibilities to list... And that's the exact reason why it doesn't show up in ORM's. You're trying to get EF, and ORM's in general, to do something that is best left up to the coder. Hell, that's even what you said in your previous post! By the way, your analogy doesn't even apply to this.

Asking questions is a skill CodeProject Forum Guidelines Google: C# How to debug code Seriously, go read these articles.
Dave Kreskowiak

desanti

Quote:

So how do you configure that behavior in code, and all possible variants? Like either keeping the modified data, dumping all the modified data, or just keeping some of it and replacing the rest, or replacing some of it based on rules, or dumping some of it based on rules, ... there's too many possibilities to list

no no , i'm telling that EF could have some rules , for example if you load data from database ( with a special command like reload ) the cached data will be overwritten. So a programmer can use this and i think it's easy to resolve the situations.EF has a Reload command but for a single object at time . If a have a list of entries that i want to reload , i should do one by one ??? why not all with a single command !!!! By your opinion , better to have a full working Reload command and let programmers to resolve the possibilities . or to have something like my second solution where i'm fooling EF telling that those objects are detached in order to resolve my problem ????!!!

desanti

Sorry , I found a new way :

Dim contextobj = (CType(context, IObjectContextAdapter)).ObjectContext
contextobj.Refresh(RefreshMode.StoreWins, context.myobjs.Local)
contextobj.Refresh(RefreshMode.StoreWins, context.mychilds.Local)

Is there anything wrong with this method ?

Dave Kreskowiak

Technically, no. As far as your business rules go, you're the only one who would know.

Asking questions is a skill CodeProject Forum Guidelines Google: C# How to debug code Seriously, go read these articles.
Dave Kreskowiak

desanti

Then , really I don't understand why a such method does not exist on DBContext directly but I should use objectContext. Because the option StoreWins means that the local cache will be overwritten with new data on my database , we have discussed this on our conversation.

Dave Kreskowiak

I've already said my piece. I'm out.

Asking questions is a skill CodeProject Forum Guidelines Google: C# How to debug code Seriously, go read these articles.
Dave Kreskowiak