This is both a general request for 'best-practise' devforce design, and also a specific question about my current scenario.

 

How would you recommend devforce be used/managed to support user-cancellation of complex edits?

 

In our app as currently designed, we have a small, fixed number of EntityManager's that are created and loaded with cached reference data at application startup.  When a user requests an edit we load the required item, Include()'ing the relevant child data, and relying on the cached reference data to auto-attach those entities.... this works perfectly!

 

If the user makes some changes to the item (I'll talk a normal Order -> OrderDetails scenario), say changing an orderdate, and then chooses to cancel their edit, we call the RejectChanges() method, and the date rolls back exactly as expected.

 

However we run into problems with adding new child items (eg, an OrderDetail), and then cancelling changes.... these items seem to remain in the EntityCache or similar in a detached state, with their generated -100 id.  This causes problems if we (for example):

 

1. Pop a new Order/OrderDetails set of data

2. Cancel Changes

3. Make some other save that resets the generated ID's back to -100

4. Another pop of a new item results in the earlier OrderDetails magically coming back to life and attaching themselves to the new Order.  Other symptoms include errors regarding multiple items with the same (-100 based) ID as the id's are recycled after the save.

 

We've been playing with specifically removing items from the EntityManager after rejecting the changes eg:

_cxt.RejectChanges; //Model state goes from Added to Detached

if (Model.EntityState == EntityState.Detached) //was freshly added until we cancelled

{

     Model.EntityAspect.RemoveFromManager(true); //Remove from the cache, don't try and save it later on

}

 

And this has definately reduced the number of issues we're seeing, but it isn't sufficient for all our scenarios (hence the general request for your recommended approach above).

 

If I can provide any more info please just ask.

Cheers,

Tim

 

Actually, there's nothing wrong with how you're using RejectChanges. I suspect that there is a bug at play here.

When RejectChanges is called, an Added entity will be removed from its EntityManager and marked as Detached. Detached means that it is not associated with any EntityManager. Therefore, the call EntityAspect.RemoveFromManager should not be necessary.

However, I'm having no luck in reproducing the issue here.

1. What version are you using? I'll attempt my repro using this version. It might be an already fixed bug.

2. Will it be possible for you to isolate this in a simple console solution and send it to me?

 

I'm seeing very similar issues with my Silverlight application. I have version 6.1.3.0d

 

I add a new entity but during my business process I may need to reject it before saving. Later when a new entity is added I get an error saying that entity -100 exists.

 

For now I'm moving these entities to Guids and my problems are gone.

 

Kr

George

Thanks for the feedback. I've tried to repro again with 6.1.3.0d but I'm still unsuccessful. My repro is perhaps too simplistic and there's probably something more going on that I can't see.

I've attached my test solution here. Would you please take a look and try to isolate the issue using this solution?

uploads/912/TestSolution.zip - uploads/912/TestSolution.zip

Thank you,

Denis

 

I can confirm that upgrading from 6.1.0 to 6.1.2 appears to have solved our issue... I can no longer repro it the same as I could under 6.1.0 anyway.

 

I'll re-post in here if it pops again under production load.

 

Cheers,

Tim

Thanks for the clarification. Just so the 3 of us (George, me and you) to be on the same page, would you be so kind to share your repro that you said you did under 6.1.0?

George has 6.1.3.0d and he says that he's seeing a similar issue so I'm wondering whether it is the same issue or not since your upgrade to 6.1.2 seems to have fixed it.

Thank you,

Denis

 

It looks like its not as clear cut as I'd hoped, as the issue still occurring at times under 6.1.2.  I have a repro app which generated the error once, but I can't make it fail again.  I'm also in silverlight/using Async calls etc.

 

I can generate the failure in my full solution pretty consistently, but not 100%, and trying the get the error to surface in a simple app is proving troublesome.  I'll revert my machine to v6.1.0 shortly, and try and get a consistent simple repro with the earlier version.

 

In the meantime, I've attached the simple silverlight ViewModel I'm using for your perusal.

 

uploads/1155/MainPageViewModel.txt - uploads/1155/MainPageViewModel.txt

 

Cheers,

Tim

 

I've had to move to using Guids for my 3 main transaction tables to overcome this and it's working without any issues.

 

I wish I had more time to spend on this but I have deadlines for 31st August. I'm battling with a HttpTimoutWithoutDetails.

 

Kr

George

Thanks for the ViewModel code. Let me take a look and see if I can get something out of it.

 

Sorry for the delay getting back to you, project work has been keeping me busy!

 

I have not been able to consistently repro in a simple application on 6.1.0.0 either :(  I've re-written the relevant portion of the application in our trunk to spin up a new EntityManage for this transaction to isolate the changes, and this has resolved the defect in-app.   Unfortunately we're going to go-live with this defect in place as the risk from the re-write is too large at this stage of the project.

 

We're not doing any cloning in our codebase, but dupes are invovled.  When the item re-attaches itself we generally see it added as a duplicate (bug D1809), although this resolved itself after the upgrade to 6.1.2.  Unfortunately this same upgrade seemed to have some perf issues merging large numbers of entities into a new EntityManager (our reference data) compared to 6.1.0, but I haven't had a chance to really get tht sorted/evaluated yet.

 

Given the complexities of running the two versions side-by-side (see my thread here: http://www.ideablade.com/forum/forum_posts.asp?TID=2939 - http://www.ideablade.com/forum/forum_posts.asp?TID=2939 ) we're staying on 6.1.0 until go-live in a few weeks time, and once it's bedded in we'll look again at rolling our ongoing dev to the latest build.

 

Ta,

Tim