Storing Multiple Changes in Entity Framework

Question

Hi there,

I'm trying to achieve a form of two phase commit using Entity Framework 1.0.

What I would like to achieve at a high level is:

1. get all the data from the database and store this in a cache.
2. modify individual entities
3. Commit all changes into the database

The problem's i've encountered so far is that caching an IQueryable is a bit pointless as it's going to go back to the database regardless. So the other option is to use IEnumberable for storing the results of a query, but that stops me inheriting one query and refining it into another (I can live with that however). The other problem is that as soon as the EntityContext expires (which i've managed to persist in the current httprequest) that's it, no changes can be tracked.

Has anyone tried to do something similar to this in the past or got any pointers?

Many thanks, Matt

jumpingmattflash.co.uk

Answer 1

Call .ToList() on your IQueryable results from the database. To then start refining into other queries use .AsQueryable(). This should solve your first problem.

As for your second problem, I'm also searching for a solution. As I understand the underlying implementation of the relationship parts of Entity Framework revolves around the ObjectStateManager in the System.Data.Objects namespace of the System.Data.Entity assembly. This in turn uses the MetadataWorkspace class in the System.Data.Metadata.Edm namespace to lookup the relationship mappings. These might be able to be used without an underlying database connection, and if so, would provide some very groovy tools to update complex object graphs.

It would be nice if the context had a Detach and Attach in a similar way to individual Entities. It looks like the next version of the Entity Framework is going to focus on these specific type of issues; more freedom when dealing with Entities and Contexts.

Answer 2

The IQueryable is just that a queryable object not the actual data.

You need to run the ToList to get the data out.

You can do what you are trying to do if you can keep the Context open and use transactionscope. In most cases however this is not possible. This would also lock the database leading to other probelms.

A better way to do it would be:

• Read the data from the database
• Dispose of the context
• Client makes any changes needed
• Open new context
• Read the data again.
• make changes by copying data from changed data to second set
• commit the changes
• dispose of the context