All,

Looking for ideas on how to do something like the following generically, but with related entities in addition to fields:

EmployeesEntity employee = new EmployeesEntity();
employee.SaveFields("save");            
employee.Orders.Add(new OrdersEntity());
employee.RollbackFields("save");

And have employee.Orders.Count = 0 afterwards.

What I want to do is this:

1. User edits (or creates) an entity and clicks "save"
2. The entity gets passed to a save routine, which based on a number of things (type of entity, whether it's new or exists in the database) adds additional entities to the graph
3. The routine attempts to save the entity recursively
4. If there is an exception, the entity gets rolled back to its original state, with the additional entities removed from the graph

Any ideas on how I might accomplish something like this?

Thanks,

Phil

psandler wrote:

All,

Looking for ideas on how to do something like the following generically, but with related entities in addition to fields:

EmployeesEntity employee = new EmployeesEntity();
employee.SaveFields("save");            
employee.Orders.Add(new OrdersEntity());
employee.RollbackFields("save");

And have employee.Orders.Count = 0 afterwards.

What I want to do is this:

1. User edits (or creates) an entity and clicks "save"
2. The entity gets passed to a save routine, which based on a number of things (type of entity, whether it's new or exists in the database) adds additional entities to the graph
3. The routine attempts to save the entity recursively
4. If there is an exception, the entity gets rolled back to its original state, with the additional entities removed from the graph

Any ideas on how I might accomplish something like this?

Thanks,

Phil

I did this, but it wasn't easy

To do this, I changed the entitycollection code so that it can save different states of itself just like the fields object can. That includes keeping state snapshots of both the .Items in the collection as well as in the removedentitiestracker. If a rollback is requested, the whole graph can roll itself back to a state using the fields rollbacks in addition to the entitycollection rollbacks.

Transactional graph versioning isn't easy. Here is a paper about this: http://arxiv.org/abs/0709.1699 Though we will have a try with it in the future.

Thanks for the replies, gents. Sounds like I need to be sure I absolutely need this before I start moving down that path.

Thanks,

Phil

psandler wrote:

Thanks for the replies, gents. Sounds like I need to be sure I absolutely need this before I start moving down that path.

Thanks,

Phil

If I had to do it again, I probably would have used serialization to copy the graph, and just replaced the entire graph with this copy in the case of a rollback. The problem with this is if you have any pointers in your code pointing to the old graph (including events, databinding, etc) you need to repoint to the copied graph.

mikeg22 wrote:

If I had to do it again, I probably would have used serialization to copy the graph, and just replaced the entire graph with this copy in the case of a rollback. The problem with this is if you have any pointers in your code pointing to the old graph (including events, databinding, etc) you need to repoint to the copied graph.

Yep, I've considered this, as we already do some cloning/copying of graphs already for importing/exporting data for test setups. I was worried about exactly the kind of side effects you are talking about.

Thanks,

Phil

psandler wrote:

mikeg22 wrote:

If I had to do it again, I probably would have used serialization to copy the graph, and just replaced the entire graph with this copy in the case of a rollback. The problem with this is if you have any pointers in your code pointing to the old graph (including events, databinding, etc) you need to repoint to the copied graph.

Yep, I've considered this, as we already do some cloning/copying of graphs already for importing/exporting data for test setups. I was worried about exactly the kind of side effects you are talking about.

Thanks,

Phil

Thats a really good idea for doing tests...I hadn't thought of that! How do you store the data when it is serialized?

mikeg22 wrote:

Thats a really good idea for doing tests...I hadn't thought of that! How do you store the data when it is serialized?

We store it to disk. It's a nice tool for testing, but there are problems too. If the model changes, the method that generates the file has to be changed, otherwise things can break in ways that can be hard to track down.